37

Ok, this has been bugging me for a while; Will cruft left over from a previous run of LaTeX ever change how my document looks?

Would the following procedures ever give me different results:

I compile my document until it stabilizes (All references resolved and such) then edit my document and recompile until it stabilizes.

vs.

I compile my document until it stabilizes (All references resolved and such) then edit my document. Now I delete everything but my *.tex and *.bib files and recompile until it stabilizes.

I'm probably just asking this due to being used to all the cruft word leaves in old documents, but it has been bugging me for a while. Does LaTeX save math and such things in the *.aux and such, and would it ever arrive at a different solution due to this saved information?

I only included the compile until it stabilizes bit, as I don't want answers about references and things; I know that in any situation where you have to compile more then once you will obviously get a different outcome if you delete the intermediate files. I'm interested in the final document as I'd share it with someone. If this is the case, then I should be careful to always delete the intermediate files and recompile before sharing my document with anyone.

Mohan
  • 15,906
Canageek
  • 17,935
  • I think the only time you have to delete the temporary files is when they get corrupted in which case you get an error. Otherwise they are overwritten upon subsequent runs, so don't see how that can be a problem. Of course there are some bugs in packages that cause issues, but in my case that has always meant that you have to run it again, after which problems resolve them self. – Peter Grill Nov 14 '12 at 01:24
  • 3
    @PeterGrill aux files are input at \begin{document} before they are over-written. bad things can happen. – David Carlisle Nov 14 '12 at 01:34
  • @cmhughes It is common language among computer people, and in the Oxford English Dictionary. The usage I used means 'stuff that builds up over time' which is similar, if note quite the same as the wikipedia definition – Canageek Nov 15 '12 at 23:55

2 Answers2

33

If your edit removes packages then that can remove definitions of things that are still in the aux file. hyperref and babel are two notable examples. In this case you get an error when the aux file is read at begin document.

It is quite possible to write commands where you get no error and just stabilise to an incorrect point if you read an aux file from a previous run after which the source file has been changed. Early versions of longtable would do this, which was why by default longtable did not try to align its parts and stabilize, you had to explicitly add \setlongtables once you had finished editing. longtable v4 introduced a more careful algorithm that internally protects itself from edits to the table and so is safe to load aux files from previous runs even if the file has been edited. (This was due to David Kastrup)

David Carlisle
  • 757,742
  • So for example, I'll never have floats moving around due to compiling with an old log file? That is good to know, thank you. – Canageek Nov 14 '12 at 01:35
  • 8
    log files are harmless, it is aux files where all the action happens. – David Carlisle Nov 14 '12 at 01:37
  • 3
    also be wary of old .ind files -- subsequent compiles could yield different page numbers in the .idx file, and if your routine doesn't include an automatic regeneration of the .ind file and an additional latex run (to insert the correct index) or maybe two (for the toc, if the first page of the index gets a different page number) you'll need to remember to do that manually. – barbara beeton Nov 14 '12 at 14:14
33

I try to explain it via examples:

Package babel

Usually package babel writes \select@language in the auxiliary files (table of contents, …) for each specified languages. Then, if some language is removed or changed, babel complains in the next LaTeX run:

! Package babel Error: You haven't loaded the option ... yet.

Package nameref/hyperref

Some packages change internal commands, e.g. nameref/hyperref add additional arguments to the internal label commands inside .aux files and to entries of the table of contents. Running again without the package might cause errors (although some common cases are catched by these packages).

Package macros inside auxiliary files

Packages can provide macros that goes into auxiliary files (.aux, .toc, …). Removing the package might result in undefined macros inside auxiliary files.

If a package adds "top level" macros inside aux files I recommend that the package adds a \providecommand statement at the begin of the .aux file to avoid trouble, if the package is no longer used. For example, zref uses \zref@newlabel for its label and adds a dummy definition at the begin of the .aux file:

\providecommand\zref@newlabel[2]{}

However this trick is hopeless (too many macros), if a package defines lots of macros (font packages, …) that might occur in text arguments (e.g. section titles, …) that go into auxiliary files.

Environment filecontents

Unless package filecontents is loaded, LaTeX's filecontents environment does not overwrite files. Thus if the TeX file writes something and rereads it for typesetting, then you get a different result, if the lines in the source file inside filecontents are changed. Because without deleting before the next LaTeX run would use the older version.

Summary

Assuming you have always a valid TeX file that compiles correctly from scratch does not mean that it runs successfully or correctly if there are left-over auxiliary files. There can be errors. Or even, if LaTeX runs without errors or warnings, the result can be wrong.

However, it takes much more time to recompiling from scratch until stabilization, therefore it saves time to work with the left-over auxiliary files.

On the other side, the auxiliary files should be cleaned up, if a more reliable and reproducible result is needed.

Heiko Oberdiek
  • 271,626