16

I have a couple of LaTeX files with the same problem. If I produce an error, fix it, and then try to compile a pdf, I get the following error.

)Runaway argument?
{{
! File ended while scanning use of \@newl@ablel.
<inserted text>
                \par
l.90 \begin{document}

If I then click on the console or trash my .aux file, it compiles fine. Any thoughts on what is going on and how to prevent this annoying extra step?

5
  • I hope you mean compile a TeX file. :) Commented Aug 7, 2013 at 19:52
  • 1
    Welcome to TeX.SX! Unfortunately, some bad errors cause corruption in the .aux file. Sometimes just passing over the error, instead of interrupting the LaTeX run, can cure it by writing a correct file at the end of the run.
    – egreg
    Commented Aug 7, 2013 at 19:53
  • But once the error is fixed and the corrupt .aux file is deleted, that file compiles fine? Obviously, not every error should produce so terrible an error. Also: is 'the same problem' due to the same bad command..?
    – jon
    Commented Aug 7, 2013 at 22:14
  • This is the weird thing. Once a file decides it wants to do this, it doesn't matter what type of error, the same problem happens. However, lots of my files recompile just fine after clicking apply. From the responses I have gotten, it sounds like I just need to deal with it.
    – user34798
    Commented Aug 8, 2013 at 0:21
  • never saw \@newl@ablel but only \@newl@bel ...
    – user4686
    Commented Jan 23, 2016 at 21:49

3 Answers 3

6

This is the nature of the beast...

TeX employs an (external) auxiliary .aux file to store information at/of every run. This file is used extensively when dealing with labels and references (see Understanding how references and labels work) since the output routine only flushes pages after having collected enough content to fill it (and perhaps more). As is evident from your error snippet, it deals with an offending \label usage.

Here's the sequence that causes the error:

  1. You compile your document.
  2. \label-information is stored in .aux. This information will be read during a subsequent compilation. If problematic code is written to the .aux, you will only pick it up in this subsequent run. However, this run itself may compile without problem.
  3. You compile your document again in order to make sure the references settle. However, now the problematic code is read in, causing the error.

Note that, even during the second compile (item 3 above) you are still writing problematic code to the .aux. So, even if you fix it and recompile, the problem will still show in the subsequent compile.

Some problems are recoverable, but others are fatal, depending on when you are writing the information to the .aux. In a worst-case scenario - when the problem persists even though you've fixed your code - delete the offending .aux and recompile (at least twice).

How do you avoid this annoying extra step? Don't make mistakes... :) Well, at least not when dealing with content written to the .aux file.

1
  • Please note my counter-answer. Commented Jan 23, 2016 at 13:30
20

Although there is already an answer to this question, I think it is wrong. TeXShop users are always complaining about this problem and hardly any other people are complaining. I've been a TeXShop fan almost since the first edition but this is its most annoying feature. It happens to me all the time in TeXShop and almost never in any other program I use, including manual command line execution.

The reason it happens is something to do with the state TeXShop leaves the aux file in when typesetting is aborted at an error. That is, if compilation stops at an error, then you fix the error and hit compile again, latex sees a bad aux file. To see that it isn't (usually) your latex error that caused the bad aux file, instead of starting the compilation again immediately, enter "x" into the window at the bottom of the console window to make latex continue to the end regardless of errors. Now fixing the error and compiling again will usually work.

As several people noted above, deleting the aux file automatically is a bad idea. What should happen (though I don't know how to automate it) is that the aux file is deleted if it wasn't written completely.

2
  • 2
    This is a great answer and clarifies a lot for me, but something still confuses me. This doesn't happen every time, but once it starts happening it rarely stops, even if the aux file is completely deleted. This suggests to me that there is something about the actual TeX file that causes TeXShop to leave the aux file in a bad state. Do you have an idea what this could be?
    – Will Sawin
    Commented Aug 25, 2017 at 7:00
  • Well guess what. VS code's latex workshop also has this issue. And what's worse, it automatically trashes the aux file to solve this. What's worser, it also trashes the bbl file. What a genius.
    – Symbol 1
    Commented Aug 30, 2021 at 1:47
3

This is an old post, but I came across it and have what I think is useful input. My observations:

  1. Most importantly for actually being able to deal with this problem (which is a constant issue every time I use TexShop): To make this go away, you don't have to trash aux files. Just enter 'q' in the console window where your error is. That causes TeX to end its run more gracefully and leave the aux files in a nicer state. If your file is now error-free, the next compile will work.

  2. Also important: You can prevent this problem (if you remember, which I often don't) by entering 'q' in the console window for the original error, before trying to compile again.

  3. The issue is not that TeXShop itself messes up the aux files. Instead, the problem is that, apparently, TeXShop starts a new compile process without gracefully ending the previous process. I can make this happen on the command line without TeXShop. If your file was giving this error in TeXShop, the same will happen on the comand line with the following steps: a. Introduce an error into the file. b. Compile. c. Fix the file. d. Kill the TeX process abruptly or just leave it hanging. e. Compile again (from a different terminal window if you left the process hanging).

  4. In my experience, once my file gets big enough, this error happens always, whenever I make an error, fix it, and recompile without hitting 'q' in the TeXShop console window. The actual error that comes up varies, but it always references a line number fairly early in the file. (My experience may be very dependent on the kinds of packages I typically run, not sure.)

Would this problem go away if TeXShop automatically killed the hanging process gracefully before compiling again? Not sure.

2
  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. - From Review
    – Miyase
    Commented Jul 8, 2023 at 1:38
  • @Miyase: I disagree entirely that this does not answer the question. If you look in the question for the question mark you see this: "Any thoughts on what is going on and how to prevent this annoying extra step?" My points 1 and 2 directly address how to avoid trashing aux files and my points 3 and 4 are thoughts on what is going on. My final sentences (outside of the numbered list) are musings about whether the TeXShop people can easily fix this. Arguably, they do not answer the question directly, but they are a small fraction of my answer. Commented Jul 10, 2023 at 0:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .