Prevent pdflatex from writing a bunch of files












110















If I create just a basic hello.tex file an compile it using



pdflatex hello.tex


The pdflatex program is creating a plethora of file which is a little annoying. Currently it writes all those files about which I really don't care:



hello.aux, hello.log, hello.nav, hello.out, hello.snm, hello.toc


Is there a way to tell pdflatex to only write hello.pdf if the build is successful ? If not, can I specify the output directory of those files ? Maybe I could just write them in /tmp.










share|improve this question




















  • 22





    Sometimes you need those extra files. For example, aux keeps information about crossreferences and the like. They won't work unless latex can read that information from the aux file.

    – Seamus
    Feb 15 '11 at 13:43






  • 6





    See this question and this question

    – Seamus
    Feb 15 '11 at 13:45






  • 2





    Try using Gummi. You'll have just the .tex file and the .pdf file. If you check out the screenshots, the "Error Output" will let you look at the log. It just doesn't leave a file behind to clutter things up. Gummi is best for small documents since it is constantly compiling to give you an almost immediate view of what you're creating.

    – DJP
    Aug 13 '11 at 21:45













  • May be you can try with arara: tex.stackexchange.com/a/87818/11232

    – user11232
    Dec 29 '12 at 1:48






  • 1





    FWIW, ConTeXt stores all the auxiliary information in a single file filename.tuc. So overall, only two extra files are written: filename.tuc and filename.log. If you want, you can compile the document using context --purge filename.tex which will delete the .tuc and .log files at the end of the run.

    – Aditya
    Sep 15 '14 at 22:17
















110















If I create just a basic hello.tex file an compile it using



pdflatex hello.tex


The pdflatex program is creating a plethora of file which is a little annoying. Currently it writes all those files about which I really don't care:



hello.aux, hello.log, hello.nav, hello.out, hello.snm, hello.toc


Is there a way to tell pdflatex to only write hello.pdf if the build is successful ? If not, can I specify the output directory of those files ? Maybe I could just write them in /tmp.










share|improve this question




















  • 22





    Sometimes you need those extra files. For example, aux keeps information about crossreferences and the like. They won't work unless latex can read that information from the aux file.

    – Seamus
    Feb 15 '11 at 13:43






  • 6





    See this question and this question

    – Seamus
    Feb 15 '11 at 13:45






  • 2





    Try using Gummi. You'll have just the .tex file and the .pdf file. If you check out the screenshots, the "Error Output" will let you look at the log. It just doesn't leave a file behind to clutter things up. Gummi is best for small documents since it is constantly compiling to give you an almost immediate view of what you're creating.

    – DJP
    Aug 13 '11 at 21:45













  • May be you can try with arara: tex.stackexchange.com/a/87818/11232

    – user11232
    Dec 29 '12 at 1:48






  • 1





    FWIW, ConTeXt stores all the auxiliary information in a single file filename.tuc. So overall, only two extra files are written: filename.tuc and filename.log. If you want, you can compile the document using context --purge filename.tex which will delete the .tuc and .log files at the end of the run.

    – Aditya
    Sep 15 '14 at 22:17














110












110








110


38






If I create just a basic hello.tex file an compile it using



pdflatex hello.tex


The pdflatex program is creating a plethora of file which is a little annoying. Currently it writes all those files about which I really don't care:



hello.aux, hello.log, hello.nav, hello.out, hello.snm, hello.toc


Is there a way to tell pdflatex to only write hello.pdf if the build is successful ? If not, can I specify the output directory of those files ? Maybe I could just write them in /tmp.










share|improve this question
















If I create just a basic hello.tex file an compile it using



pdflatex hello.tex


The pdflatex program is creating a plethora of file which is a little annoying. Currently it writes all those files about which I really don't care:



hello.aux, hello.log, hello.nav, hello.out, hello.snm, hello.toc


Is there a way to tell pdflatex to only write hello.pdf if the build is successful ? If not, can I specify the output directory of those files ? Maybe I could just write them in /tmp.







auxiliary-files






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 2 '13 at 9:59









lockstep

191k52587719




191k52587719










asked Feb 15 '11 at 13:35









fouronnesfouronnes

717289




717289








  • 22





    Sometimes you need those extra files. For example, aux keeps information about crossreferences and the like. They won't work unless latex can read that information from the aux file.

    – Seamus
    Feb 15 '11 at 13:43






  • 6





    See this question and this question

    – Seamus
    Feb 15 '11 at 13:45






  • 2





    Try using Gummi. You'll have just the .tex file and the .pdf file. If you check out the screenshots, the "Error Output" will let you look at the log. It just doesn't leave a file behind to clutter things up. Gummi is best for small documents since it is constantly compiling to give you an almost immediate view of what you're creating.

    – DJP
    Aug 13 '11 at 21:45













  • May be you can try with arara: tex.stackexchange.com/a/87818/11232

    – user11232
    Dec 29 '12 at 1:48






  • 1





    FWIW, ConTeXt stores all the auxiliary information in a single file filename.tuc. So overall, only two extra files are written: filename.tuc and filename.log. If you want, you can compile the document using context --purge filename.tex which will delete the .tuc and .log files at the end of the run.

    – Aditya
    Sep 15 '14 at 22:17














  • 22





    Sometimes you need those extra files. For example, aux keeps information about crossreferences and the like. They won't work unless latex can read that information from the aux file.

    – Seamus
    Feb 15 '11 at 13:43






  • 6





    See this question and this question

    – Seamus
    Feb 15 '11 at 13:45






  • 2





    Try using Gummi. You'll have just the .tex file and the .pdf file. If you check out the screenshots, the "Error Output" will let you look at the log. It just doesn't leave a file behind to clutter things up. Gummi is best for small documents since it is constantly compiling to give you an almost immediate view of what you're creating.

    – DJP
    Aug 13 '11 at 21:45













  • May be you can try with arara: tex.stackexchange.com/a/87818/11232

    – user11232
    Dec 29 '12 at 1:48






  • 1





    FWIW, ConTeXt stores all the auxiliary information in a single file filename.tuc. So overall, only two extra files are written: filename.tuc and filename.log. If you want, you can compile the document using context --purge filename.tex which will delete the .tuc and .log files at the end of the run.

    – Aditya
    Sep 15 '14 at 22:17








22




22





Sometimes you need those extra files. For example, aux keeps information about crossreferences and the like. They won't work unless latex can read that information from the aux file.

– Seamus
Feb 15 '11 at 13:43





Sometimes you need those extra files. For example, aux keeps information about crossreferences and the like. They won't work unless latex can read that information from the aux file.

– Seamus
Feb 15 '11 at 13:43




6




6





See this question and this question

– Seamus
Feb 15 '11 at 13:45





See this question and this question

– Seamus
Feb 15 '11 at 13:45




2




2





Try using Gummi. You'll have just the .tex file and the .pdf file. If you check out the screenshots, the "Error Output" will let you look at the log. It just doesn't leave a file behind to clutter things up. Gummi is best for small documents since it is constantly compiling to give you an almost immediate view of what you're creating.

– DJP
Aug 13 '11 at 21:45







Try using Gummi. You'll have just the .tex file and the .pdf file. If you check out the screenshots, the "Error Output" will let you look at the log. It just doesn't leave a file behind to clutter things up. Gummi is best for small documents since it is constantly compiling to give you an almost immediate view of what you're creating.

– DJP
Aug 13 '11 at 21:45















May be you can try with arara: tex.stackexchange.com/a/87818/11232

– user11232
Dec 29 '12 at 1:48





May be you can try with arara: tex.stackexchange.com/a/87818/11232

– user11232
Dec 29 '12 at 1:48




1




1





FWIW, ConTeXt stores all the auxiliary information in a single file filename.tuc. So overall, only two extra files are written: filename.tuc and filename.log. If you want, you can compile the document using context --purge filename.tex which will delete the .tuc and .log files at the end of the run.

– Aditya
Sep 15 '14 at 22:17





FWIW, ConTeXt stores all the auxiliary information in a single file filename.tuc. So overall, only two extra files are written: filename.tuc and filename.log. If you want, you can compile the document using context --purge filename.tex which will delete the .tuc and .log files at the end of the run.

– Aditya
Sep 15 '14 at 22:17










18 Answers
18






active

oldest

votes


















95














You might not care about these files, but pdflatex does quite a bit. These files hold information collected during the first run(s) and are needed to build the final PDF with correct ToC, references, PDF bookmarks, etc.



Your can delete these files afterwards, e.g. manually or using a front-end tool like latexmk (-c option). However, future compilations of the PDF would then need again several compiler runs.



You can define an output directory for all files using the -output-directory command line argument of pdflatex. After compilation you can then move the PDF in the current directory.



With MiKTeX, you can specify a directory in which all the auxiliary files are put (but not the PDF output) by using the -aux-directory command line argument. You can even combine -output-directory and -aux-directory.






share|improve this answer





















  • 21





    Why does LaTeX do this? Why doesn't it do the multiple runs in the background, keeping toc, references, bookmarks, etc. in memory instead of cluttering the filesystem?

    – Jonathan Baldwin
    Oct 24 '13 at 2:19






  • 9





    @JonathanBaldwin TeX (upon which LaTeX is built) was written in 1978, before the PC era. It was designed to work in resource constrained environments, and therefore uses explicit multiple passes instead of keeping stuff in memory (and then breaking everything like word does).

    – Paul de Vrieze
    Mar 30 '14 at 20:51






  • 3





    Texmaker has an option called "Use a "build" subdirectory for output files" that will put all extra files in a folder called build automatically.

    – qwr
    Oct 17 '16 at 5:02











  • @MartinScharrer How do you automate the moving of the output pdf to a separate directory? Is it possible? Thanks.

    – Nanashi No Gombe
    Mar 23 '18 at 9:10



















55














In addition to Martin's answer, I thought it might be useful to explain why LaTeX creates all these extra files. Let's take the example of the .aux file.



Let's say you have a label in your document and a reference to it somewhere above where the label occurs. When pdflatex reads your .tex file, it reads the ref first. Now, it doesn't know what to do with this ref: it hasn't yet encountered what it's referring to. Now when pdflatex reaches the label, it makes a note of what the label is referring to. By "makes a note" I mean it writes something to the .aux file that says roughly "when you encounter references to this, this is what is meant".



Then, on a second pdflatex run, when it reaches the reference, it looks in the .aux file and it knows what it is supposed to refer to and can substitute in the relevant text.



Auxiliary files are used for lots of other similar things (like tables of contents, lists of figures and so on). They are annoying, but deleting them after each run would break things. A lot.






share|improve this answer



















  • 38





    I don't mean to raise a flamewar here, but maybe it's more fair to say that the .aux file is a kludge which is due to the current implementation of TeX. When I compile a C program, the compiler doesn't write a file with the memory offsets assigned to every variable, so it isn't clear why TeX should do something similar. Simply, it's an artifact from the past.

    – Federico Poloni
    Oct 6 '11 at 11:17






  • 7





    Actually, the C compiler does create such file, it's the object file. Without knowing where the variables are, the linker would have pretty hard time linking everything together. If you run make clean, it usually remove these files for you, which is similar what you with do with tools like latexmk. You are right that in most cases with TeX, this could be resolved instead by TeX itself making multiple passes through the file, storing the data in memory. I believe I have seen someone trying to do something like that, but I don't really see why.

    – Jan Hlavacek
    Oct 23 '11 at 16:23






  • 22





    The C compiler creates the .o file only if it is given an explicit command-line switch to do it. Otherwise it keeps all in memory and spits out only the executable file. Moreover, when you modify only a portion of your program, typically most .o files are unchanged, so they are effectively useful as a "compilation cache" to reduce work. In contrast, typically, when you add a paragraph at the end of a .tex file the references change and you have to compile twice, so there is no saving. Tell me, how many other languages do you know where you normally have to compile your file twice?

    – Federico Poloni
    Feb 15 '12 at 8:35






  • 1





    You can use the .aux files as cache too, if you use for example includeonly.

    – Juri Robl
    Jun 11 '12 at 9:51






  • 4





    @FedericoPoloni While a C compiler can compile in a single pass (iff you don't want fancy optimizations), more modern languages can not be compiled in a single pass (e.g. Java or C#). In addition, only toy programs get compiled by passing all source files directly to the compiler. I can agree with you though that in this day and age there is little reason for TeX and LaTeX not to perform those passes by themselves.

    – Paul de Vrieze
    Mar 30 '14 at 20:56



















29














You already got lots of very good answers explaining why pdflatex needs all those auxiliary files. However you might still feel frustrated about having to live with all those files polluting a directory where (I'm guessing) you would like to keep all your LaTeX documents and their corresponding .pdf outputs.




The best solution is to keep one directory for each document you have.




You can keep, for example, a main Documents folder and then individual Paper1, Paper2, ... folders; each with their own main.tex file. Then you can happily let LaTeX store whatever auxiliary files it wants in their respective folders. The difference is that now, for you, there is a clear structure of where your documents are.






share|improve this answer



















  • 3





    pdflatex also has a CLI option for -aux-directory=dir, so you could simply have all your aux files and such. I remember seeing an easy way to make an alias to do this with just the pdflatex command, but I can't find it

    – MercurialMadnessMan
    Feb 15 '12 at 18:02






  • 3





    @MercurialMadnessMan: The version of pdflatex I have under Debian Squeeze does not include an -aux-directory option. I think that is a MiKTeX option.

    – SabreWolfy
    Jun 3 '12 at 12:31








  • 1





    I am the boss of my computer. If I don't want my computer to make these files, it should not make these files. I understand that in the 80-ies it was wasteful to recompute everything. Today, my computer can compile my 1-2 page much faster than all the time I lose from auxiliary file mess that has been created.

    – mnr
    Sep 28 '18 at 15:31



















26














TeX writes the .log file. It contains more information about processing the job than what is shown on the console. It's very useful for debugging.



LaTeX writes the .aux and .toc files. They are used for managing cross-references and table-of-contents information. Since TeX's organism digests the input document from beginning to end, once per job, there's no other way to have a part of the document change based on later content.



The beamer class writes .snm and .nav files. The .snm file is to assist you with including images of slides into an article version of the document. The .nav file assists in creating navigation bars on slides. Beamer is not apparently set up to suppress writing those files if they are not needed (i.e., if you do not need the functionality they enable).



The hyperref package writes the .out file to assist in creating bookmarks in the pdf file. Sometimes this isn't needed; I looked at the last few jobs I had which used hyperref and the .out files are empty. Again, this doesn't seem suppressable.



You can write the auxiliary files to a temporary directory. Then you'll have to instruct TeX to look in that temporary directory. Also you will have to make sure that the included auxiliary files are the right ones, not ones placed in the temporary directory by another process.



I think it's best to learn to live with these files. If you don't want them after you're "done" with writing the document, just delete them.






share|improve this answer





















  • 2





    If everyone thought according to your last paragraph, we wouldn't even have the printing press let alone computers and LaTeX. Rejecting the status quo is the first step of progress.

    – Jonathan Baldwin
    Oct 24 '13 at 2:36






  • 3





    @JonathanBaldwin: Not all stati quo are created equal. IMO the work needed to force LaTeX to not use auxiliary files will not lead to inventions on the level of the printing press.

    – Matthew Leingang
    Nov 1 '13 at 15:23



















13














This is quite an old post with many good answers but, surprisingly, none of them mention nofiles. There are times when you create documents with:




  • no cross references (with ref and label)

  • no citations (with cite)

  • no table of contents.


In these cases you don't want latex to create the long list of files mentioned above and you can tell it not to using nofiles:



documentclass{article}
nofiles
begin{document}
Hello world
end{document}


If you are running (pdf)latex "by hand" then the only files created will be the .log file and the .dvi (or .pdf file). If you are using something ike synctex then there will be a few more files for controlling the automatic compilation.






share|improve this answer

































    7














    You can use this workaround as a rough guide because I am not sure whether you are a Windows user.



    Step 1: create a batch file



    rem batch.bat takes a input name without extension.
    echo off

    rem remove the previous PDF output to avoid confusion
    rem when compilation fails.
    del %1.pdf

    pdflatex %1
    pdflatex %1
    rem list other programs such as
    rem invoking bibtex, etc.

    del %1.log
    del %1.aux
    del %1.nav
    del %1.out
    del %1.toc

    rem other operations such as deleting or
    rem renaming files.


    Save it in a dedicated, safe folder such that reformatting hard disk will not lose it.



    Step 2: set the PATH



    enter image description here



    Step 3: Configure TeXnicCenter



    enter image description here



    enter image description here






    share|improve this answer



















    • 1





      Two compiler passes may not be enough. In fact, theoretically there may be any number of LaTeX passes needed.

      – Andrey Vihrov
      Aug 6 '11 at 3:50











    • @Andrey: Of course. The batch above must be adapted to suit our need.

      – xport
      Aug 6 '11 at 4:04



















    7














    Solution for Emacs with AucTeX, just run



    M-x TeX-clean


    This does not get rid of any temporary directories that are created, just files






    share|improve this answer



















    • 4





      Or just run C-c C-c Clean. Note that C-c C-c Clean All deletes also DVI or PDF file.

      – Paul Gaborit
      Jun 25 '12 at 5:51



















    6














    I have the (Mac) application Hazel watching my Articles folder and subfolders, with rules that delete all these auxiliary files after a certain interval since they were last modified. Usually it's two days or so. It cleans up files for papers I'm not currently working on.



    Addressing the concerns about deletion raised above, if such files are needed in the future they can be created anew. Though this will require multiple runs, latexmk automatically runs the tex engine the necessary number of times, so they will be created.






    share|improve this answer


























    • Never new about Hazel - that's great!

      – Werner
      Aug 6 '11 at 2:06



















    6














    For those like-minded as me, and running linux:



    #! /bin/bash

    echo -n > .hidden
    for i in *.out; do echo "$i" >> .hidden; done
    for i in *.log; do echo "$i" >> .hidden; done
    for i in *.aux; do echo "$i" >> .hidden; done
    for i in *.bbl; do echo "$i" >> .hidden; done
    for i in *.blg; do echo "$i" >> .hidden; done
    for i in *.dvi; do echo "$i" >> .hidden; done
    for i in *.toc; do echo "$i" >> .hidden; done
    for i in *.synctex.gz; do echo "$i" >> .hidden; done


    Put this bash shell in your path, to do that put this line:



    export PATH=$PATH:∼/scripts


    into your ∼/.bashrc file
    (in this example ~/scripts is the folder containing the bash shell above), this can be at the end of that file. Maybe you also have to run this file from the terminal, but this will ensure you can run this script anywhere, wherever you're keeping it.



    Now you run this script in the terminal, while being in the directory needing cleaning and run the shell. That means that if the script is named tex.clean, you'd browse to the folder needing cleaning in terminal, enter



    tex.clean


    in the terminal, and browse to the file in the graphical file browser, and it should be clean :)



    All the file with endings mentioned in the shell will be written to that directory's .hidden file. This means they will be hidden, but still usable :).



    In nautilus (at least in fedora distributions) ctrl+h will show or hide hidden files.



    P.S. I tried to have this as detailed as I could so people new to bash and command line like me could use this. I hope I succeeded :).






    share|improve this answer





















    • 5





      You can avoid repetition of code by writing for i in *.{out,log,aux,bbl,blg,dvi,toc,synctex.gz}.

      – Ryan Reich
      Jul 6 '12 at 1:22











    • I didn't know that writing file names to a file called .hidden will hide them like all other files that start with .. In which unices is that supported? (not Mac OS as far as I can tell)

      – Matthew Leingang
      Nov 20 '13 at 20:59













    • It's not unix, only nautilus file manager (and possibly others, most certainly its forks nemo and caja) supports hiding via .hidden. If you browse that directory via ls you'll continue to see those files. Still, it's a fairly good solution to remove bothering files if you are a nautilus user.

      – p91paul
      Mar 30 '15 at 9:48





















    4














    Though this is an older question, I want to contribute something that might help people who love clean workspaces. I created a shell script that deletes all junk files at once. It will work on Mac and Linux; with some adjustments Windows should be possible too. Download the file "cleanlatexjunk.sh" from my repository and follow the instructions:



    https://github.com/cgraumann/LatexUtils




    1. Open Preferences/Build in TexStudio

    2. Select Advanced options at the bottom

    3. Add a new user command with the name cleanjunk

    4. As the command, enter:

      "/PATH/TO/SCRIPT/cleanlatexjunk.sh" -fp ?me ?a)

      and change /PATH/TO/SCRIPT/ accordingly

    5. In the meta-command for Build & View add | txs:///cleanjunk at the end


    Important: As described by people before, the "junk" files are actually needed. Therefore you should also adjust your build workflow to do multiple compiles in a row. This assures that all TOCs and links are rendered correctly. After two or three compile runs, you can safely use my script as described.



    Now every build & view execution should result in a clean workspace :-)






    share|improve this answer
























    • Welcome to TeX.SX!

      – Heiko Oberdiek
      Jun 8 '15 at 14:27



















    2














    # write a makefile and remove all of the unwanted files after compilation.   
    # change your folder structure as you see fit.
    # Folder structure
    DOCDIR = doc/
    TEXDIR = doc/tex/

    # The compiler and the -output-directory flag
    TCC = pdflatex
    TEXFLAGS = -output-directory

    documentation:
    $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename1.tex
    $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename2.tex
    $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename3.tex
    rm -f $(DOCDIR)*.log
    rm -f $(DOCDIR)*.aux
    rm -f $(DOCDIR)*.toc
    rm -f *.pdf
    rm -f *.aux
    rm -f *.toc
    rm -f *.log

    # Though if using this method you have to be careful with the image paths in
    # your tex source file. They're taken from the makefile directory.

    # To use the file type >> make documentation << in a terminal

    # You can also do it like this

    documentation:
    $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename1.tex
    $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename2.tex
    $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename3.tex

    clean:
    rm -f $(DOCDIR)*.log
    rm -f $(DOCDIR)*.aux
    rm -f $(DOCDIR)*.toc
    rm -f *.pdf
    rm -f *.aux
    rm -f *.toc
    rm -f *.log

    # now >> make clean documentation << outputs with no crappy files
    # and >> make documentation << outputs with the crappy files
    # and >> make clean << cleans all the crappy files.





    share|improve this answer

































      2














      Going back to why so many extra files (and why the C compiler doesn’t – apparently – do this): C is a language designed for single-pass compilation. Names must be defined before used. LaTeX isn’t. In a world with tight memory, the way to handle this is to use two passes, storing information needed for the second pass on the way through.



      In today’s world with big memories, this is not entirely necessary. A LaTeX compiler could in principle store everything needed in internal tables and go back and patch in information as it became available.



      If you really want to manage this properly, you need to work out how to use a makefile (or other similar build manager) to decide automatically when a second run is needed (some cases are obvious, like when you change your bibliography, others less so). Read this if you want to find out about Makefiles and LaTeX in detail.






      share|improve this answer



















      • 1





        "C is a language designed for single-pass compilation." False. C uses multiple passes (preprocessing, compiling, maybe some optimizing, linking, maybe more optimizing) and a C compiler may even choose to dump 5 million files into pwd that are useless after the passes are finished. Most compilers don't unless you tell them to.

        – Jonathan Baldwin
        Nov 7 '13 at 0:42



















      2














      For Mac OS X 18.* users (I'm using Mountain Lion) the .hidden file list does not appear to work any more for Finder. An alternative to the previous script would be



      for i in *.{out,log,aux,toc,bbl,dvi,blg,synctex.gz};
      do chflags hidden $i;
      done


      which also works in some flavors of Linux.






      share|improve this answer

































        1














        There's still another option, you can merge the Clean button and the close button in TexMaker so when you close all the auxiliary files are deleted. This way you don't have to remember to Clean all the time yet you can still use the auxiliary files as long as you don't close.



        This can be done downloading the sourcecode. The important file is texmaker.cpp and the processes are CleanAll and fileClose






        share|improve this answer
























        • This is a feature in Configure Texmaker > Commands > Launch the "Clean" tool when exiting Texmaker

          – qwr
          Oct 17 '16 at 5:10



















        1














        Texmaker includes an option to "use a build directory for output files" which kind of does the trick.



        If you enable this setting Texmaker creates a 'build' folder in the same directory as the document .tex file. It automatically cleans the old output and outputs into the build folder instead.



        The setting works well but isn't perfect. For example I've found that after adding a new citation to the document Bibtex complained when it couldn't find the .aux file. I had to copy the aux file back out of the build folder to compile the document. I'm not sure if there's a way to fix that yet.






        share|improve this answer

































          1














          These files are needed but yes, there's no need to have them at the same path. Use this bash script to avoid cluttering of the folder containing your .tex file:



          # plcl: pdflatex clean
          infile=`readlink -f "$1"`
          inpath=`dirname "$infile"`
          tmpath="/tmp/pdflatex`echo "$inpath" | sed -e 's///-/g'`"

          mkdir "$tmpath"
          pdflatex -output-directory "$tmpath" "$1"
          mv "$tmpath"/*pdf "$inpath"


          This requires bash and sed.






          share|improve this answer































            1














            The LaTeX build wrapper ltx2any may be a solution. This does not prevent the creation of all the auxiliary files, but places them in another directory, which you can specify



            ltx2any -t path_where_you_want_the_auxiliary_files_to_go filename.tex 


            This path can very well be a tmp folder.



            For more options, see ltx2any --help.






            share|improve this answer































              0














              Just do it: It's dirty but useful.



              cd /usr/bin && mv pdflatex __backup_real_pdflatex
              vim pdflatex


              #!/bin/bash

              fname="$1"
              /usr/bin/__backup_real_pdflatex $@ && rm -f "$fname."{log,nav,out,aux,toc,snm}
              exit $?


              WARNING: The script above is not tested even once!!





              share








              New contributor




              Recolic Keghart is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
              Check out our Code of Conduct.




















                Your Answer








                StackExchange.ready(function() {
                var channelOptions = {
                tags: "".split(" "),
                id: "85"
                };
                initTagRenderer("".split(" "), "".split(" "), channelOptions);

                StackExchange.using("externalEditor", function() {
                // Have to fire editor after snippets, if snippets enabled
                if (StackExchange.settings.snippets.snippetsEnabled) {
                StackExchange.using("snippets", function() {
                createEditor();
                });
                }
                else {
                createEditor();
                }
                });

                function createEditor() {
                StackExchange.prepareEditor({
                heartbeatType: 'answer',
                autoActivateHeartbeat: false,
                convertImagesToLinks: false,
                noModals: true,
                showLowRepImageUploadWarning: true,
                reputationToPostImages: null,
                bindNavPrevention: true,
                postfix: "",
                imageUploader: {
                brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
                contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
                allowUrls: true
                },
                onDemand: true,
                discardSelector: ".discard-answer"
                ,immediatelyShowMarkdownHelp:true
                });


                }
                });














                draft saved

                draft discarded


















                StackExchange.ready(
                function () {
                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f11123%2fprevent-pdflatex-from-writing-a-bunch-of-files%23new-answer', 'question_page');
                }
                );

                Post as a guest















                Required, but never shown

























                18 Answers
                18






                active

                oldest

                votes








                18 Answers
                18






                active

                oldest

                votes









                active

                oldest

                votes






                active

                oldest

                votes









                95














                You might not care about these files, but pdflatex does quite a bit. These files hold information collected during the first run(s) and are needed to build the final PDF with correct ToC, references, PDF bookmarks, etc.



                Your can delete these files afterwards, e.g. manually or using a front-end tool like latexmk (-c option). However, future compilations of the PDF would then need again several compiler runs.



                You can define an output directory for all files using the -output-directory command line argument of pdflatex. After compilation you can then move the PDF in the current directory.



                With MiKTeX, you can specify a directory in which all the auxiliary files are put (but not the PDF output) by using the -aux-directory command line argument. You can even combine -output-directory and -aux-directory.






                share|improve this answer





















                • 21





                  Why does LaTeX do this? Why doesn't it do the multiple runs in the background, keeping toc, references, bookmarks, etc. in memory instead of cluttering the filesystem?

                  – Jonathan Baldwin
                  Oct 24 '13 at 2:19






                • 9





                  @JonathanBaldwin TeX (upon which LaTeX is built) was written in 1978, before the PC era. It was designed to work in resource constrained environments, and therefore uses explicit multiple passes instead of keeping stuff in memory (and then breaking everything like word does).

                  – Paul de Vrieze
                  Mar 30 '14 at 20:51






                • 3





                  Texmaker has an option called "Use a "build" subdirectory for output files" that will put all extra files in a folder called build automatically.

                  – qwr
                  Oct 17 '16 at 5:02











                • @MartinScharrer How do you automate the moving of the output pdf to a separate directory? Is it possible? Thanks.

                  – Nanashi No Gombe
                  Mar 23 '18 at 9:10
















                95














                You might not care about these files, but pdflatex does quite a bit. These files hold information collected during the first run(s) and are needed to build the final PDF with correct ToC, references, PDF bookmarks, etc.



                Your can delete these files afterwards, e.g. manually or using a front-end tool like latexmk (-c option). However, future compilations of the PDF would then need again several compiler runs.



                You can define an output directory for all files using the -output-directory command line argument of pdflatex. After compilation you can then move the PDF in the current directory.



                With MiKTeX, you can specify a directory in which all the auxiliary files are put (but not the PDF output) by using the -aux-directory command line argument. You can even combine -output-directory and -aux-directory.






                share|improve this answer





















                • 21





                  Why does LaTeX do this? Why doesn't it do the multiple runs in the background, keeping toc, references, bookmarks, etc. in memory instead of cluttering the filesystem?

                  – Jonathan Baldwin
                  Oct 24 '13 at 2:19






                • 9





                  @JonathanBaldwin TeX (upon which LaTeX is built) was written in 1978, before the PC era. It was designed to work in resource constrained environments, and therefore uses explicit multiple passes instead of keeping stuff in memory (and then breaking everything like word does).

                  – Paul de Vrieze
                  Mar 30 '14 at 20:51






                • 3





                  Texmaker has an option called "Use a "build" subdirectory for output files" that will put all extra files in a folder called build automatically.

                  – qwr
                  Oct 17 '16 at 5:02











                • @MartinScharrer How do you automate the moving of the output pdf to a separate directory? Is it possible? Thanks.

                  – Nanashi No Gombe
                  Mar 23 '18 at 9:10














                95












                95








                95







                You might not care about these files, but pdflatex does quite a bit. These files hold information collected during the first run(s) and are needed to build the final PDF with correct ToC, references, PDF bookmarks, etc.



                Your can delete these files afterwards, e.g. manually or using a front-end tool like latexmk (-c option). However, future compilations of the PDF would then need again several compiler runs.



                You can define an output directory for all files using the -output-directory command line argument of pdflatex. After compilation you can then move the PDF in the current directory.



                With MiKTeX, you can specify a directory in which all the auxiliary files are put (but not the PDF output) by using the -aux-directory command line argument. You can even combine -output-directory and -aux-directory.






                share|improve this answer















                You might not care about these files, but pdflatex does quite a bit. These files hold information collected during the first run(s) and are needed to build the final PDF with correct ToC, references, PDF bookmarks, etc.



                Your can delete these files afterwards, e.g. manually or using a front-end tool like latexmk (-c option). However, future compilations of the PDF would then need again several compiler runs.



                You can define an output directory for all files using the -output-directory command line argument of pdflatex. After compilation you can then move the PDF in the current directory.



                With MiKTeX, you can specify a directory in which all the auxiliary files are put (but not the PDF output) by using the -aux-directory command line argument. You can even combine -output-directory and -aux-directory.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Feb 5 '12 at 11:40









                doncherry

                34.9k23135208




                34.9k23135208










                answered Feb 15 '11 at 13:43









                Martin ScharrerMartin Scharrer

                201k45636818




                201k45636818








                • 21





                  Why does LaTeX do this? Why doesn't it do the multiple runs in the background, keeping toc, references, bookmarks, etc. in memory instead of cluttering the filesystem?

                  – Jonathan Baldwin
                  Oct 24 '13 at 2:19






                • 9





                  @JonathanBaldwin TeX (upon which LaTeX is built) was written in 1978, before the PC era. It was designed to work in resource constrained environments, and therefore uses explicit multiple passes instead of keeping stuff in memory (and then breaking everything like word does).

                  – Paul de Vrieze
                  Mar 30 '14 at 20:51






                • 3





                  Texmaker has an option called "Use a "build" subdirectory for output files" that will put all extra files in a folder called build automatically.

                  – qwr
                  Oct 17 '16 at 5:02











                • @MartinScharrer How do you automate the moving of the output pdf to a separate directory? Is it possible? Thanks.

                  – Nanashi No Gombe
                  Mar 23 '18 at 9:10














                • 21





                  Why does LaTeX do this? Why doesn't it do the multiple runs in the background, keeping toc, references, bookmarks, etc. in memory instead of cluttering the filesystem?

                  – Jonathan Baldwin
                  Oct 24 '13 at 2:19






                • 9





                  @JonathanBaldwin TeX (upon which LaTeX is built) was written in 1978, before the PC era. It was designed to work in resource constrained environments, and therefore uses explicit multiple passes instead of keeping stuff in memory (and then breaking everything like word does).

                  – Paul de Vrieze
                  Mar 30 '14 at 20:51






                • 3





                  Texmaker has an option called "Use a "build" subdirectory for output files" that will put all extra files in a folder called build automatically.

                  – qwr
                  Oct 17 '16 at 5:02











                • @MartinScharrer How do you automate the moving of the output pdf to a separate directory? Is it possible? Thanks.

                  – Nanashi No Gombe
                  Mar 23 '18 at 9:10








                21




                21





                Why does LaTeX do this? Why doesn't it do the multiple runs in the background, keeping toc, references, bookmarks, etc. in memory instead of cluttering the filesystem?

                – Jonathan Baldwin
                Oct 24 '13 at 2:19





                Why does LaTeX do this? Why doesn't it do the multiple runs in the background, keeping toc, references, bookmarks, etc. in memory instead of cluttering the filesystem?

                – Jonathan Baldwin
                Oct 24 '13 at 2:19




                9




                9





                @JonathanBaldwin TeX (upon which LaTeX is built) was written in 1978, before the PC era. It was designed to work in resource constrained environments, and therefore uses explicit multiple passes instead of keeping stuff in memory (and then breaking everything like word does).

                – Paul de Vrieze
                Mar 30 '14 at 20:51





                @JonathanBaldwin TeX (upon which LaTeX is built) was written in 1978, before the PC era. It was designed to work in resource constrained environments, and therefore uses explicit multiple passes instead of keeping stuff in memory (and then breaking everything like word does).

                – Paul de Vrieze
                Mar 30 '14 at 20:51




                3




                3





                Texmaker has an option called "Use a "build" subdirectory for output files" that will put all extra files in a folder called build automatically.

                – qwr
                Oct 17 '16 at 5:02





                Texmaker has an option called "Use a "build" subdirectory for output files" that will put all extra files in a folder called build automatically.

                – qwr
                Oct 17 '16 at 5:02













                @MartinScharrer How do you automate the moving of the output pdf to a separate directory? Is it possible? Thanks.

                – Nanashi No Gombe
                Mar 23 '18 at 9:10





                @MartinScharrer How do you automate the moving of the output pdf to a separate directory? Is it possible? Thanks.

                – Nanashi No Gombe
                Mar 23 '18 at 9:10











                55














                In addition to Martin's answer, I thought it might be useful to explain why LaTeX creates all these extra files. Let's take the example of the .aux file.



                Let's say you have a label in your document and a reference to it somewhere above where the label occurs. When pdflatex reads your .tex file, it reads the ref first. Now, it doesn't know what to do with this ref: it hasn't yet encountered what it's referring to. Now when pdflatex reaches the label, it makes a note of what the label is referring to. By "makes a note" I mean it writes something to the .aux file that says roughly "when you encounter references to this, this is what is meant".



                Then, on a second pdflatex run, when it reaches the reference, it looks in the .aux file and it knows what it is supposed to refer to and can substitute in the relevant text.



                Auxiliary files are used for lots of other similar things (like tables of contents, lists of figures and so on). They are annoying, but deleting them after each run would break things. A lot.






                share|improve this answer



















                • 38





                  I don't mean to raise a flamewar here, but maybe it's more fair to say that the .aux file is a kludge which is due to the current implementation of TeX. When I compile a C program, the compiler doesn't write a file with the memory offsets assigned to every variable, so it isn't clear why TeX should do something similar. Simply, it's an artifact from the past.

                  – Federico Poloni
                  Oct 6 '11 at 11:17






                • 7





                  Actually, the C compiler does create such file, it's the object file. Without knowing where the variables are, the linker would have pretty hard time linking everything together. If you run make clean, it usually remove these files for you, which is similar what you with do with tools like latexmk. You are right that in most cases with TeX, this could be resolved instead by TeX itself making multiple passes through the file, storing the data in memory. I believe I have seen someone trying to do something like that, but I don't really see why.

                  – Jan Hlavacek
                  Oct 23 '11 at 16:23






                • 22





                  The C compiler creates the .o file only if it is given an explicit command-line switch to do it. Otherwise it keeps all in memory and spits out only the executable file. Moreover, when you modify only a portion of your program, typically most .o files are unchanged, so they are effectively useful as a "compilation cache" to reduce work. In contrast, typically, when you add a paragraph at the end of a .tex file the references change and you have to compile twice, so there is no saving. Tell me, how many other languages do you know where you normally have to compile your file twice?

                  – Federico Poloni
                  Feb 15 '12 at 8:35






                • 1





                  You can use the .aux files as cache too, if you use for example includeonly.

                  – Juri Robl
                  Jun 11 '12 at 9:51






                • 4





                  @FedericoPoloni While a C compiler can compile in a single pass (iff you don't want fancy optimizations), more modern languages can not be compiled in a single pass (e.g. Java or C#). In addition, only toy programs get compiled by passing all source files directly to the compiler. I can agree with you though that in this day and age there is little reason for TeX and LaTeX not to perform those passes by themselves.

                  – Paul de Vrieze
                  Mar 30 '14 at 20:56
















                55














                In addition to Martin's answer, I thought it might be useful to explain why LaTeX creates all these extra files. Let's take the example of the .aux file.



                Let's say you have a label in your document and a reference to it somewhere above where the label occurs. When pdflatex reads your .tex file, it reads the ref first. Now, it doesn't know what to do with this ref: it hasn't yet encountered what it's referring to. Now when pdflatex reaches the label, it makes a note of what the label is referring to. By "makes a note" I mean it writes something to the .aux file that says roughly "when you encounter references to this, this is what is meant".



                Then, on a second pdflatex run, when it reaches the reference, it looks in the .aux file and it knows what it is supposed to refer to and can substitute in the relevant text.



                Auxiliary files are used for lots of other similar things (like tables of contents, lists of figures and so on). They are annoying, but deleting them after each run would break things. A lot.






                share|improve this answer



















                • 38





                  I don't mean to raise a flamewar here, but maybe it's more fair to say that the .aux file is a kludge which is due to the current implementation of TeX. When I compile a C program, the compiler doesn't write a file with the memory offsets assigned to every variable, so it isn't clear why TeX should do something similar. Simply, it's an artifact from the past.

                  – Federico Poloni
                  Oct 6 '11 at 11:17






                • 7





                  Actually, the C compiler does create such file, it's the object file. Without knowing where the variables are, the linker would have pretty hard time linking everything together. If you run make clean, it usually remove these files for you, which is similar what you with do with tools like latexmk. You are right that in most cases with TeX, this could be resolved instead by TeX itself making multiple passes through the file, storing the data in memory. I believe I have seen someone trying to do something like that, but I don't really see why.

                  – Jan Hlavacek
                  Oct 23 '11 at 16:23






                • 22





                  The C compiler creates the .o file only if it is given an explicit command-line switch to do it. Otherwise it keeps all in memory and spits out only the executable file. Moreover, when you modify only a portion of your program, typically most .o files are unchanged, so they are effectively useful as a "compilation cache" to reduce work. In contrast, typically, when you add a paragraph at the end of a .tex file the references change and you have to compile twice, so there is no saving. Tell me, how many other languages do you know where you normally have to compile your file twice?

                  – Federico Poloni
                  Feb 15 '12 at 8:35






                • 1





                  You can use the .aux files as cache too, if you use for example includeonly.

                  – Juri Robl
                  Jun 11 '12 at 9:51






                • 4





                  @FedericoPoloni While a C compiler can compile in a single pass (iff you don't want fancy optimizations), more modern languages can not be compiled in a single pass (e.g. Java or C#). In addition, only toy programs get compiled by passing all source files directly to the compiler. I can agree with you though that in this day and age there is little reason for TeX and LaTeX not to perform those passes by themselves.

                  – Paul de Vrieze
                  Mar 30 '14 at 20:56














                55












                55








                55







                In addition to Martin's answer, I thought it might be useful to explain why LaTeX creates all these extra files. Let's take the example of the .aux file.



                Let's say you have a label in your document and a reference to it somewhere above where the label occurs. When pdflatex reads your .tex file, it reads the ref first. Now, it doesn't know what to do with this ref: it hasn't yet encountered what it's referring to. Now when pdflatex reaches the label, it makes a note of what the label is referring to. By "makes a note" I mean it writes something to the .aux file that says roughly "when you encounter references to this, this is what is meant".



                Then, on a second pdflatex run, when it reaches the reference, it looks in the .aux file and it knows what it is supposed to refer to and can substitute in the relevant text.



                Auxiliary files are used for lots of other similar things (like tables of contents, lists of figures and so on). They are annoying, but deleting them after each run would break things. A lot.






                share|improve this answer













                In addition to Martin's answer, I thought it might be useful to explain why LaTeX creates all these extra files. Let's take the example of the .aux file.



                Let's say you have a label in your document and a reference to it somewhere above where the label occurs. When pdflatex reads your .tex file, it reads the ref first. Now, it doesn't know what to do with this ref: it hasn't yet encountered what it's referring to. Now when pdflatex reaches the label, it makes a note of what the label is referring to. By "makes a note" I mean it writes something to the .aux file that says roughly "when you encounter references to this, this is what is meant".



                Then, on a second pdflatex run, when it reaches the reference, it looks in the .aux file and it knows what it is supposed to refer to and can substitute in the relevant text.



                Auxiliary files are used for lots of other similar things (like tables of contents, lists of figures and so on). They are annoying, but deleting them after each run would break things. A lot.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Feb 15 '11 at 14:07









                SeamusSeamus

                45.3k35217332




                45.3k35217332








                • 38





                  I don't mean to raise a flamewar here, but maybe it's more fair to say that the .aux file is a kludge which is due to the current implementation of TeX. When I compile a C program, the compiler doesn't write a file with the memory offsets assigned to every variable, so it isn't clear why TeX should do something similar. Simply, it's an artifact from the past.

                  – Federico Poloni
                  Oct 6 '11 at 11:17






                • 7





                  Actually, the C compiler does create such file, it's the object file. Without knowing where the variables are, the linker would have pretty hard time linking everything together. If you run make clean, it usually remove these files for you, which is similar what you with do with tools like latexmk. You are right that in most cases with TeX, this could be resolved instead by TeX itself making multiple passes through the file, storing the data in memory. I believe I have seen someone trying to do something like that, but I don't really see why.

                  – Jan Hlavacek
                  Oct 23 '11 at 16:23






                • 22





                  The C compiler creates the .o file only if it is given an explicit command-line switch to do it. Otherwise it keeps all in memory and spits out only the executable file. Moreover, when you modify only a portion of your program, typically most .o files are unchanged, so they are effectively useful as a "compilation cache" to reduce work. In contrast, typically, when you add a paragraph at the end of a .tex file the references change and you have to compile twice, so there is no saving. Tell me, how many other languages do you know where you normally have to compile your file twice?

                  – Federico Poloni
                  Feb 15 '12 at 8:35






                • 1





                  You can use the .aux files as cache too, if you use for example includeonly.

                  – Juri Robl
                  Jun 11 '12 at 9:51






                • 4





                  @FedericoPoloni While a C compiler can compile in a single pass (iff you don't want fancy optimizations), more modern languages can not be compiled in a single pass (e.g. Java or C#). In addition, only toy programs get compiled by passing all source files directly to the compiler. I can agree with you though that in this day and age there is little reason for TeX and LaTeX not to perform those passes by themselves.

                  – Paul de Vrieze
                  Mar 30 '14 at 20:56














                • 38





                  I don't mean to raise a flamewar here, but maybe it's more fair to say that the .aux file is a kludge which is due to the current implementation of TeX. When I compile a C program, the compiler doesn't write a file with the memory offsets assigned to every variable, so it isn't clear why TeX should do something similar. Simply, it's an artifact from the past.

                  – Federico Poloni
                  Oct 6 '11 at 11:17






                • 7





                  Actually, the C compiler does create such file, it's the object file. Without knowing where the variables are, the linker would have pretty hard time linking everything together. If you run make clean, it usually remove these files for you, which is similar what you with do with tools like latexmk. You are right that in most cases with TeX, this could be resolved instead by TeX itself making multiple passes through the file, storing the data in memory. I believe I have seen someone trying to do something like that, but I don't really see why.

                  – Jan Hlavacek
                  Oct 23 '11 at 16:23






                • 22





                  The C compiler creates the .o file only if it is given an explicit command-line switch to do it. Otherwise it keeps all in memory and spits out only the executable file. Moreover, when you modify only a portion of your program, typically most .o files are unchanged, so they are effectively useful as a "compilation cache" to reduce work. In contrast, typically, when you add a paragraph at the end of a .tex file the references change and you have to compile twice, so there is no saving. Tell me, how many other languages do you know where you normally have to compile your file twice?

                  – Federico Poloni
                  Feb 15 '12 at 8:35






                • 1





                  You can use the .aux files as cache too, if you use for example includeonly.

                  – Juri Robl
                  Jun 11 '12 at 9:51






                • 4





                  @FedericoPoloni While a C compiler can compile in a single pass (iff you don't want fancy optimizations), more modern languages can not be compiled in a single pass (e.g. Java or C#). In addition, only toy programs get compiled by passing all source files directly to the compiler. I can agree with you though that in this day and age there is little reason for TeX and LaTeX not to perform those passes by themselves.

                  – Paul de Vrieze
                  Mar 30 '14 at 20:56








                38




                38





                I don't mean to raise a flamewar here, but maybe it's more fair to say that the .aux file is a kludge which is due to the current implementation of TeX. When I compile a C program, the compiler doesn't write a file with the memory offsets assigned to every variable, so it isn't clear why TeX should do something similar. Simply, it's an artifact from the past.

                – Federico Poloni
                Oct 6 '11 at 11:17





                I don't mean to raise a flamewar here, but maybe it's more fair to say that the .aux file is a kludge which is due to the current implementation of TeX. When I compile a C program, the compiler doesn't write a file with the memory offsets assigned to every variable, so it isn't clear why TeX should do something similar. Simply, it's an artifact from the past.

                – Federico Poloni
                Oct 6 '11 at 11:17




                7




                7





                Actually, the C compiler does create such file, it's the object file. Without knowing where the variables are, the linker would have pretty hard time linking everything together. If you run make clean, it usually remove these files for you, which is similar what you with do with tools like latexmk. You are right that in most cases with TeX, this could be resolved instead by TeX itself making multiple passes through the file, storing the data in memory. I believe I have seen someone trying to do something like that, but I don't really see why.

                – Jan Hlavacek
                Oct 23 '11 at 16:23





                Actually, the C compiler does create such file, it's the object file. Without knowing where the variables are, the linker would have pretty hard time linking everything together. If you run make clean, it usually remove these files for you, which is similar what you with do with tools like latexmk. You are right that in most cases with TeX, this could be resolved instead by TeX itself making multiple passes through the file, storing the data in memory. I believe I have seen someone trying to do something like that, but I don't really see why.

                – Jan Hlavacek
                Oct 23 '11 at 16:23




                22




                22





                The C compiler creates the .o file only if it is given an explicit command-line switch to do it. Otherwise it keeps all in memory and spits out only the executable file. Moreover, when you modify only a portion of your program, typically most .o files are unchanged, so they are effectively useful as a "compilation cache" to reduce work. In contrast, typically, when you add a paragraph at the end of a .tex file the references change and you have to compile twice, so there is no saving. Tell me, how many other languages do you know where you normally have to compile your file twice?

                – Federico Poloni
                Feb 15 '12 at 8:35





                The C compiler creates the .o file only if it is given an explicit command-line switch to do it. Otherwise it keeps all in memory and spits out only the executable file. Moreover, when you modify only a portion of your program, typically most .o files are unchanged, so they are effectively useful as a "compilation cache" to reduce work. In contrast, typically, when you add a paragraph at the end of a .tex file the references change and you have to compile twice, so there is no saving. Tell me, how many other languages do you know where you normally have to compile your file twice?

                – Federico Poloni
                Feb 15 '12 at 8:35




                1




                1





                You can use the .aux files as cache too, if you use for example includeonly.

                – Juri Robl
                Jun 11 '12 at 9:51





                You can use the .aux files as cache too, if you use for example includeonly.

                – Juri Robl
                Jun 11 '12 at 9:51




                4




                4





                @FedericoPoloni While a C compiler can compile in a single pass (iff you don't want fancy optimizations), more modern languages can not be compiled in a single pass (e.g. Java or C#). In addition, only toy programs get compiled by passing all source files directly to the compiler. I can agree with you though that in this day and age there is little reason for TeX and LaTeX not to perform those passes by themselves.

                – Paul de Vrieze
                Mar 30 '14 at 20:56





                @FedericoPoloni While a C compiler can compile in a single pass (iff you don't want fancy optimizations), more modern languages can not be compiled in a single pass (e.g. Java or C#). In addition, only toy programs get compiled by passing all source files directly to the compiler. I can agree with you though that in this day and age there is little reason for TeX and LaTeX not to perform those passes by themselves.

                – Paul de Vrieze
                Mar 30 '14 at 20:56











                29














                You already got lots of very good answers explaining why pdflatex needs all those auxiliary files. However you might still feel frustrated about having to live with all those files polluting a directory where (I'm guessing) you would like to keep all your LaTeX documents and their corresponding .pdf outputs.




                The best solution is to keep one directory for each document you have.




                You can keep, for example, a main Documents folder and then individual Paper1, Paper2, ... folders; each with their own main.tex file. Then you can happily let LaTeX store whatever auxiliary files it wants in their respective folders. The difference is that now, for you, there is a clear structure of where your documents are.






                share|improve this answer



















                • 3





                  pdflatex also has a CLI option for -aux-directory=dir, so you could simply have all your aux files and such. I remember seeing an easy way to make an alias to do this with just the pdflatex command, but I can't find it

                  – MercurialMadnessMan
                  Feb 15 '12 at 18:02






                • 3





                  @MercurialMadnessMan: The version of pdflatex I have under Debian Squeeze does not include an -aux-directory option. I think that is a MiKTeX option.

                  – SabreWolfy
                  Jun 3 '12 at 12:31








                • 1





                  I am the boss of my computer. If I don't want my computer to make these files, it should not make these files. I understand that in the 80-ies it was wasteful to recompute everything. Today, my computer can compile my 1-2 page much faster than all the time I lose from auxiliary file mess that has been created.

                  – mnr
                  Sep 28 '18 at 15:31
















                29














                You already got lots of very good answers explaining why pdflatex needs all those auxiliary files. However you might still feel frustrated about having to live with all those files polluting a directory where (I'm guessing) you would like to keep all your LaTeX documents and their corresponding .pdf outputs.




                The best solution is to keep one directory for each document you have.




                You can keep, for example, a main Documents folder and then individual Paper1, Paper2, ... folders; each with their own main.tex file. Then you can happily let LaTeX store whatever auxiliary files it wants in their respective folders. The difference is that now, for you, there is a clear structure of where your documents are.






                share|improve this answer



















                • 3





                  pdflatex also has a CLI option for -aux-directory=dir, so you could simply have all your aux files and such. I remember seeing an easy way to make an alias to do this with just the pdflatex command, but I can't find it

                  – MercurialMadnessMan
                  Feb 15 '12 at 18:02






                • 3





                  @MercurialMadnessMan: The version of pdflatex I have under Debian Squeeze does not include an -aux-directory option. I think that is a MiKTeX option.

                  – SabreWolfy
                  Jun 3 '12 at 12:31








                • 1





                  I am the boss of my computer. If I don't want my computer to make these files, it should not make these files. I understand that in the 80-ies it was wasteful to recompute everything. Today, my computer can compile my 1-2 page much faster than all the time I lose from auxiliary file mess that has been created.

                  – mnr
                  Sep 28 '18 at 15:31














                29












                29








                29







                You already got lots of very good answers explaining why pdflatex needs all those auxiliary files. However you might still feel frustrated about having to live with all those files polluting a directory where (I'm guessing) you would like to keep all your LaTeX documents and their corresponding .pdf outputs.




                The best solution is to keep one directory for each document you have.




                You can keep, for example, a main Documents folder and then individual Paper1, Paper2, ... folders; each with their own main.tex file. Then you can happily let LaTeX store whatever auxiliary files it wants in their respective folders. The difference is that now, for you, there is a clear structure of where your documents are.






                share|improve this answer













                You already got lots of very good answers explaining why pdflatex needs all those auxiliary files. However you might still feel frustrated about having to live with all those files polluting a directory where (I'm guessing) you would like to keep all your LaTeX documents and their corresponding .pdf outputs.




                The best solution is to keep one directory for each document you have.




                You can keep, for example, a main Documents folder and then individual Paper1, Paper2, ... folders; each with their own main.tex file. Then you can happily let LaTeX store whatever auxiliary files it wants in their respective folders. The difference is that now, for you, there is a clear structure of where your documents are.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Feb 15 '11 at 16:17









                Juan A. NavarroJuan A. Navarro

                36k27115160




                36k27115160








                • 3





                  pdflatex also has a CLI option for -aux-directory=dir, so you could simply have all your aux files and such. I remember seeing an easy way to make an alias to do this with just the pdflatex command, but I can't find it

                  – MercurialMadnessMan
                  Feb 15 '12 at 18:02






                • 3





                  @MercurialMadnessMan: The version of pdflatex I have under Debian Squeeze does not include an -aux-directory option. I think that is a MiKTeX option.

                  – SabreWolfy
                  Jun 3 '12 at 12:31








                • 1





                  I am the boss of my computer. If I don't want my computer to make these files, it should not make these files. I understand that in the 80-ies it was wasteful to recompute everything. Today, my computer can compile my 1-2 page much faster than all the time I lose from auxiliary file mess that has been created.

                  – mnr
                  Sep 28 '18 at 15:31














                • 3





                  pdflatex also has a CLI option for -aux-directory=dir, so you could simply have all your aux files and such. I remember seeing an easy way to make an alias to do this with just the pdflatex command, but I can't find it

                  – MercurialMadnessMan
                  Feb 15 '12 at 18:02






                • 3





                  @MercurialMadnessMan: The version of pdflatex I have under Debian Squeeze does not include an -aux-directory option. I think that is a MiKTeX option.

                  – SabreWolfy
                  Jun 3 '12 at 12:31








                • 1





                  I am the boss of my computer. If I don't want my computer to make these files, it should not make these files. I understand that in the 80-ies it was wasteful to recompute everything. Today, my computer can compile my 1-2 page much faster than all the time I lose from auxiliary file mess that has been created.

                  – mnr
                  Sep 28 '18 at 15:31








                3




                3





                pdflatex also has a CLI option for -aux-directory=dir, so you could simply have all your aux files and such. I remember seeing an easy way to make an alias to do this with just the pdflatex command, but I can't find it

                – MercurialMadnessMan
                Feb 15 '12 at 18:02





                pdflatex also has a CLI option for -aux-directory=dir, so you could simply have all your aux files and such. I remember seeing an easy way to make an alias to do this with just the pdflatex command, but I can't find it

                – MercurialMadnessMan
                Feb 15 '12 at 18:02




                3




                3





                @MercurialMadnessMan: The version of pdflatex I have under Debian Squeeze does not include an -aux-directory option. I think that is a MiKTeX option.

                – SabreWolfy
                Jun 3 '12 at 12:31







                @MercurialMadnessMan: The version of pdflatex I have under Debian Squeeze does not include an -aux-directory option. I think that is a MiKTeX option.

                – SabreWolfy
                Jun 3 '12 at 12:31






                1




                1





                I am the boss of my computer. If I don't want my computer to make these files, it should not make these files. I understand that in the 80-ies it was wasteful to recompute everything. Today, my computer can compile my 1-2 page much faster than all the time I lose from auxiliary file mess that has been created.

                – mnr
                Sep 28 '18 at 15:31





                I am the boss of my computer. If I don't want my computer to make these files, it should not make these files. I understand that in the 80-ies it was wasteful to recompute everything. Today, my computer can compile my 1-2 page much faster than all the time I lose from auxiliary file mess that has been created.

                – mnr
                Sep 28 '18 at 15:31











                26














                TeX writes the .log file. It contains more information about processing the job than what is shown on the console. It's very useful for debugging.



                LaTeX writes the .aux and .toc files. They are used for managing cross-references and table-of-contents information. Since TeX's organism digests the input document from beginning to end, once per job, there's no other way to have a part of the document change based on later content.



                The beamer class writes .snm and .nav files. The .snm file is to assist you with including images of slides into an article version of the document. The .nav file assists in creating navigation bars on slides. Beamer is not apparently set up to suppress writing those files if they are not needed (i.e., if you do not need the functionality they enable).



                The hyperref package writes the .out file to assist in creating bookmarks in the pdf file. Sometimes this isn't needed; I looked at the last few jobs I had which used hyperref and the .out files are empty. Again, this doesn't seem suppressable.



                You can write the auxiliary files to a temporary directory. Then you'll have to instruct TeX to look in that temporary directory. Also you will have to make sure that the included auxiliary files are the right ones, not ones placed in the temporary directory by another process.



                I think it's best to learn to live with these files. If you don't want them after you're "done" with writing the document, just delete them.






                share|improve this answer





















                • 2





                  If everyone thought according to your last paragraph, we wouldn't even have the printing press let alone computers and LaTeX. Rejecting the status quo is the first step of progress.

                  – Jonathan Baldwin
                  Oct 24 '13 at 2:36






                • 3





                  @JonathanBaldwin: Not all stati quo are created equal. IMO the work needed to force LaTeX to not use auxiliary files will not lead to inventions on the level of the printing press.

                  – Matthew Leingang
                  Nov 1 '13 at 15:23
















                26














                TeX writes the .log file. It contains more information about processing the job than what is shown on the console. It's very useful for debugging.



                LaTeX writes the .aux and .toc files. They are used for managing cross-references and table-of-contents information. Since TeX's organism digests the input document from beginning to end, once per job, there's no other way to have a part of the document change based on later content.



                The beamer class writes .snm and .nav files. The .snm file is to assist you with including images of slides into an article version of the document. The .nav file assists in creating navigation bars on slides. Beamer is not apparently set up to suppress writing those files if they are not needed (i.e., if you do not need the functionality they enable).



                The hyperref package writes the .out file to assist in creating bookmarks in the pdf file. Sometimes this isn't needed; I looked at the last few jobs I had which used hyperref and the .out files are empty. Again, this doesn't seem suppressable.



                You can write the auxiliary files to a temporary directory. Then you'll have to instruct TeX to look in that temporary directory. Also you will have to make sure that the included auxiliary files are the right ones, not ones placed in the temporary directory by another process.



                I think it's best to learn to live with these files. If you don't want them after you're "done" with writing the document, just delete them.






                share|improve this answer





















                • 2





                  If everyone thought according to your last paragraph, we wouldn't even have the printing press let alone computers and LaTeX. Rejecting the status quo is the first step of progress.

                  – Jonathan Baldwin
                  Oct 24 '13 at 2:36






                • 3





                  @JonathanBaldwin: Not all stati quo are created equal. IMO the work needed to force LaTeX to not use auxiliary files will not lead to inventions on the level of the printing press.

                  – Matthew Leingang
                  Nov 1 '13 at 15:23














                26












                26








                26







                TeX writes the .log file. It contains more information about processing the job than what is shown on the console. It's very useful for debugging.



                LaTeX writes the .aux and .toc files. They are used for managing cross-references and table-of-contents information. Since TeX's organism digests the input document from beginning to end, once per job, there's no other way to have a part of the document change based on later content.



                The beamer class writes .snm and .nav files. The .snm file is to assist you with including images of slides into an article version of the document. The .nav file assists in creating navigation bars on slides. Beamer is not apparently set up to suppress writing those files if they are not needed (i.e., if you do not need the functionality they enable).



                The hyperref package writes the .out file to assist in creating bookmarks in the pdf file. Sometimes this isn't needed; I looked at the last few jobs I had which used hyperref and the .out files are empty. Again, this doesn't seem suppressable.



                You can write the auxiliary files to a temporary directory. Then you'll have to instruct TeX to look in that temporary directory. Also you will have to make sure that the included auxiliary files are the right ones, not ones placed in the temporary directory by another process.



                I think it's best to learn to live with these files. If you don't want them after you're "done" with writing the document, just delete them.






                share|improve this answer















                TeX writes the .log file. It contains more information about processing the job than what is shown on the console. It's very useful for debugging.



                LaTeX writes the .aux and .toc files. They are used for managing cross-references and table-of-contents information. Since TeX's organism digests the input document from beginning to end, once per job, there's no other way to have a part of the document change based on later content.



                The beamer class writes .snm and .nav files. The .snm file is to assist you with including images of slides into an article version of the document. The .nav file assists in creating navigation bars on slides. Beamer is not apparently set up to suppress writing those files if they are not needed (i.e., if you do not need the functionality they enable).



                The hyperref package writes the .out file to assist in creating bookmarks in the pdf file. Sometimes this isn't needed; I looked at the last few jobs I had which used hyperref and the .out files are empty. Again, this doesn't seem suppressable.



                You can write the auxiliary files to a temporary directory. Then you'll have to instruct TeX to look in that temporary directory. Also you will have to make sure that the included auxiliary files are the right ones, not ones placed in the temporary directory by another process.



                I think it's best to learn to live with these files. If you don't want them after you're "done" with writing the document, just delete them.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Aug 13 '11 at 20:58

























                answered Feb 15 '11 at 14:36









                Matthew LeingangMatthew Leingang

                35k10106177




                35k10106177








                • 2





                  If everyone thought according to your last paragraph, we wouldn't even have the printing press let alone computers and LaTeX. Rejecting the status quo is the first step of progress.

                  – Jonathan Baldwin
                  Oct 24 '13 at 2:36






                • 3





                  @JonathanBaldwin: Not all stati quo are created equal. IMO the work needed to force LaTeX to not use auxiliary files will not lead to inventions on the level of the printing press.

                  – Matthew Leingang
                  Nov 1 '13 at 15:23














                • 2





                  If everyone thought according to your last paragraph, we wouldn't even have the printing press let alone computers and LaTeX. Rejecting the status quo is the first step of progress.

                  – Jonathan Baldwin
                  Oct 24 '13 at 2:36






                • 3





                  @JonathanBaldwin: Not all stati quo are created equal. IMO the work needed to force LaTeX to not use auxiliary files will not lead to inventions on the level of the printing press.

                  – Matthew Leingang
                  Nov 1 '13 at 15:23








                2




                2





                If everyone thought according to your last paragraph, we wouldn't even have the printing press let alone computers and LaTeX. Rejecting the status quo is the first step of progress.

                – Jonathan Baldwin
                Oct 24 '13 at 2:36





                If everyone thought according to your last paragraph, we wouldn't even have the printing press let alone computers and LaTeX. Rejecting the status quo is the first step of progress.

                – Jonathan Baldwin
                Oct 24 '13 at 2:36




                3




                3





                @JonathanBaldwin: Not all stati quo are created equal. IMO the work needed to force LaTeX to not use auxiliary files will not lead to inventions on the level of the printing press.

                – Matthew Leingang
                Nov 1 '13 at 15:23





                @JonathanBaldwin: Not all stati quo are created equal. IMO the work needed to force LaTeX to not use auxiliary files will not lead to inventions on the level of the printing press.

                – Matthew Leingang
                Nov 1 '13 at 15:23











                13














                This is quite an old post with many good answers but, surprisingly, none of them mention nofiles. There are times when you create documents with:




                • no cross references (with ref and label)

                • no citations (with cite)

                • no table of contents.


                In these cases you don't want latex to create the long list of files mentioned above and you can tell it not to using nofiles:



                documentclass{article}
                nofiles
                begin{document}
                Hello world
                end{document}


                If you are running (pdf)latex "by hand" then the only files created will be the .log file and the .dvi (or .pdf file). If you are using something ike synctex then there will be a few more files for controlling the automatic compilation.






                share|improve this answer






























                  13














                  This is quite an old post with many good answers but, surprisingly, none of them mention nofiles. There are times when you create documents with:




                  • no cross references (with ref and label)

                  • no citations (with cite)

                  • no table of contents.


                  In these cases you don't want latex to create the long list of files mentioned above and you can tell it not to using nofiles:



                  documentclass{article}
                  nofiles
                  begin{document}
                  Hello world
                  end{document}


                  If you are running (pdf)latex "by hand" then the only files created will be the .log file and the .dvi (or .pdf file). If you are using something ike synctex then there will be a few more files for controlling the automatic compilation.






                  share|improve this answer




























                    13












                    13








                    13







                    This is quite an old post with many good answers but, surprisingly, none of them mention nofiles. There are times when you create documents with:




                    • no cross references (with ref and label)

                    • no citations (with cite)

                    • no table of contents.


                    In these cases you don't want latex to create the long list of files mentioned above and you can tell it not to using nofiles:



                    documentclass{article}
                    nofiles
                    begin{document}
                    Hello world
                    end{document}


                    If you are running (pdf)latex "by hand" then the only files created will be the .log file and the .dvi (or .pdf file). If you are using something ike synctex then there will be a few more files for controlling the automatic compilation.






                    share|improve this answer















                    This is quite an old post with many good answers but, surprisingly, none of them mention nofiles. There are times when you create documents with:




                    • no cross references (with ref and label)

                    • no citations (with cite)

                    • no table of contents.


                    In these cases you don't want latex to create the long list of files mentioned above and you can tell it not to using nofiles:



                    documentclass{article}
                    nofiles
                    begin{document}
                    Hello world
                    end{document}


                    If you are running (pdf)latex "by hand" then the only files created will be the .log file and the .dvi (or .pdf file). If you are using something ike synctex then there will be a few more files for controlling the automatic compilation.







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Apr 19 '15 at 12:45

























                    answered Sep 15 '14 at 21:32









                    AndrewAndrew

                    30.6k34381




                    30.6k34381























                        7














                        You can use this workaround as a rough guide because I am not sure whether you are a Windows user.



                        Step 1: create a batch file



                        rem batch.bat takes a input name without extension.
                        echo off

                        rem remove the previous PDF output to avoid confusion
                        rem when compilation fails.
                        del %1.pdf

                        pdflatex %1
                        pdflatex %1
                        rem list other programs such as
                        rem invoking bibtex, etc.

                        del %1.log
                        del %1.aux
                        del %1.nav
                        del %1.out
                        del %1.toc

                        rem other operations such as deleting or
                        rem renaming files.


                        Save it in a dedicated, safe folder such that reformatting hard disk will not lose it.



                        Step 2: set the PATH



                        enter image description here



                        Step 3: Configure TeXnicCenter



                        enter image description here



                        enter image description here






                        share|improve this answer



















                        • 1





                          Two compiler passes may not be enough. In fact, theoretically there may be any number of LaTeX passes needed.

                          – Andrey Vihrov
                          Aug 6 '11 at 3:50











                        • @Andrey: Of course. The batch above must be adapted to suit our need.

                          – xport
                          Aug 6 '11 at 4:04
















                        7














                        You can use this workaround as a rough guide because I am not sure whether you are a Windows user.



                        Step 1: create a batch file



                        rem batch.bat takes a input name without extension.
                        echo off

                        rem remove the previous PDF output to avoid confusion
                        rem when compilation fails.
                        del %1.pdf

                        pdflatex %1
                        pdflatex %1
                        rem list other programs such as
                        rem invoking bibtex, etc.

                        del %1.log
                        del %1.aux
                        del %1.nav
                        del %1.out
                        del %1.toc

                        rem other operations such as deleting or
                        rem renaming files.


                        Save it in a dedicated, safe folder such that reformatting hard disk will not lose it.



                        Step 2: set the PATH



                        enter image description here



                        Step 3: Configure TeXnicCenter



                        enter image description here



                        enter image description here






                        share|improve this answer



















                        • 1





                          Two compiler passes may not be enough. In fact, theoretically there may be any number of LaTeX passes needed.

                          – Andrey Vihrov
                          Aug 6 '11 at 3:50











                        • @Andrey: Of course. The batch above must be adapted to suit our need.

                          – xport
                          Aug 6 '11 at 4:04














                        7












                        7








                        7







                        You can use this workaround as a rough guide because I am not sure whether you are a Windows user.



                        Step 1: create a batch file



                        rem batch.bat takes a input name without extension.
                        echo off

                        rem remove the previous PDF output to avoid confusion
                        rem when compilation fails.
                        del %1.pdf

                        pdflatex %1
                        pdflatex %1
                        rem list other programs such as
                        rem invoking bibtex, etc.

                        del %1.log
                        del %1.aux
                        del %1.nav
                        del %1.out
                        del %1.toc

                        rem other operations such as deleting or
                        rem renaming files.


                        Save it in a dedicated, safe folder such that reformatting hard disk will not lose it.



                        Step 2: set the PATH



                        enter image description here



                        Step 3: Configure TeXnicCenter



                        enter image description here



                        enter image description here






                        share|improve this answer













                        You can use this workaround as a rough guide because I am not sure whether you are a Windows user.



                        Step 1: create a batch file



                        rem batch.bat takes a input name without extension.
                        echo off

                        rem remove the previous PDF output to avoid confusion
                        rem when compilation fails.
                        del %1.pdf

                        pdflatex %1
                        pdflatex %1
                        rem list other programs such as
                        rem invoking bibtex, etc.

                        del %1.log
                        del %1.aux
                        del %1.nav
                        del %1.out
                        del %1.toc

                        rem other operations such as deleting or
                        rem renaming files.


                        Save it in a dedicated, safe folder such that reformatting hard disk will not lose it.



                        Step 2: set the PATH



                        enter image description here



                        Step 3: Configure TeXnicCenter



                        enter image description here



                        enter image description here







                        share|improve this answer












                        share|improve this answer



                        share|improve this answer










                        answered Aug 5 '11 at 21:44









                        xportxport

                        21.9k30138261




                        21.9k30138261








                        • 1





                          Two compiler passes may not be enough. In fact, theoretically there may be any number of LaTeX passes needed.

                          – Andrey Vihrov
                          Aug 6 '11 at 3:50











                        • @Andrey: Of course. The batch above must be adapted to suit our need.

                          – xport
                          Aug 6 '11 at 4:04














                        • 1





                          Two compiler passes may not be enough. In fact, theoretically there may be any number of LaTeX passes needed.

                          – Andrey Vihrov
                          Aug 6 '11 at 3:50











                        • @Andrey: Of course. The batch above must be adapted to suit our need.

                          – xport
                          Aug 6 '11 at 4:04








                        1




                        1





                        Two compiler passes may not be enough. In fact, theoretically there may be any number of LaTeX passes needed.

                        – Andrey Vihrov
                        Aug 6 '11 at 3:50





                        Two compiler passes may not be enough. In fact, theoretically there may be any number of LaTeX passes needed.

                        – Andrey Vihrov
                        Aug 6 '11 at 3:50













                        @Andrey: Of course. The batch above must be adapted to suit our need.

                        – xport
                        Aug 6 '11 at 4:04





                        @Andrey: Of course. The batch above must be adapted to suit our need.

                        – xport
                        Aug 6 '11 at 4:04











                        7














                        Solution for Emacs with AucTeX, just run



                        M-x TeX-clean


                        This does not get rid of any temporary directories that are created, just files






                        share|improve this answer



















                        • 4





                          Or just run C-c C-c Clean. Note that C-c C-c Clean All deletes also DVI or PDF file.

                          – Paul Gaborit
                          Jun 25 '12 at 5:51
















                        7














                        Solution for Emacs with AucTeX, just run



                        M-x TeX-clean


                        This does not get rid of any temporary directories that are created, just files






                        share|improve this answer



















                        • 4





                          Or just run C-c C-c Clean. Note that C-c C-c Clean All deletes also DVI or PDF file.

                          – Paul Gaborit
                          Jun 25 '12 at 5:51














                        7












                        7








                        7







                        Solution for Emacs with AucTeX, just run



                        M-x TeX-clean


                        This does not get rid of any temporary directories that are created, just files






                        share|improve this answer













                        Solution for Emacs with AucTeX, just run



                        M-x TeX-clean


                        This does not get rid of any temporary directories that are created, just files







                        share|improve this answer












                        share|improve this answer



                        share|improve this answer










                        answered Oct 6 '11 at 7:36









                        ImadImad

                        33137




                        33137








                        • 4





                          Or just run C-c C-c Clean. Note that C-c C-c Clean All deletes also DVI or PDF file.

                          – Paul Gaborit
                          Jun 25 '12 at 5:51














                        • 4





                          Or just run C-c C-c Clean. Note that C-c C-c Clean All deletes also DVI or PDF file.

                          – Paul Gaborit
                          Jun 25 '12 at 5:51








                        4




                        4





                        Or just run C-c C-c Clean. Note that C-c C-c Clean All deletes also DVI or PDF file.

                        – Paul Gaborit
                        Jun 25 '12 at 5:51





                        Or just run C-c C-c Clean. Note that C-c C-c Clean All deletes also DVI or PDF file.

                        – Paul Gaborit
                        Jun 25 '12 at 5:51











                        6














                        I have the (Mac) application Hazel watching my Articles folder and subfolders, with rules that delete all these auxiliary files after a certain interval since they were last modified. Usually it's two days or so. It cleans up files for papers I'm not currently working on.



                        Addressing the concerns about deletion raised above, if such files are needed in the future they can be created anew. Though this will require multiple runs, latexmk automatically runs the tex engine the necessary number of times, so they will be created.






                        share|improve this answer


























                        • Never new about Hazel - that's great!

                          – Werner
                          Aug 6 '11 at 2:06
















                        6














                        I have the (Mac) application Hazel watching my Articles folder and subfolders, with rules that delete all these auxiliary files after a certain interval since they were last modified. Usually it's two days or so. It cleans up files for papers I'm not currently working on.



                        Addressing the concerns about deletion raised above, if such files are needed in the future they can be created anew. Though this will require multiple runs, latexmk automatically runs the tex engine the necessary number of times, so they will be created.






                        share|improve this answer


























                        • Never new about Hazel - that's great!

                          – Werner
                          Aug 6 '11 at 2:06














                        6












                        6








                        6







                        I have the (Mac) application Hazel watching my Articles folder and subfolders, with rules that delete all these auxiliary files after a certain interval since they were last modified. Usually it's two days or so. It cleans up files for papers I'm not currently working on.



                        Addressing the concerns about deletion raised above, if such files are needed in the future they can be created anew. Though this will require multiple runs, latexmk automatically runs the tex engine the necessary number of times, so they will be created.






                        share|improve this answer















                        I have the (Mac) application Hazel watching my Articles folder and subfolders, with rules that delete all these auxiliary files after a certain interval since they were last modified. Usually it's two days or so. It cleans up files for papers I'm not currently working on.



                        Addressing the concerns about deletion raised above, if such files are needed in the future they can be created anew. Though this will require multiple runs, latexmk automatically runs the tex engine the necessary number of times, so they will be created.







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited Aug 7 '11 at 0:00

























                        answered Aug 5 '11 at 21:00









                        ChristopherEChristopherE

                        32129




                        32129













                        • Never new about Hazel - that's great!

                          – Werner
                          Aug 6 '11 at 2:06



















                        • Never new about Hazel - that's great!

                          – Werner
                          Aug 6 '11 at 2:06

















                        Never new about Hazel - that's great!

                        – Werner
                        Aug 6 '11 at 2:06





                        Never new about Hazel - that's great!

                        – Werner
                        Aug 6 '11 at 2:06











                        6














                        For those like-minded as me, and running linux:



                        #! /bin/bash

                        echo -n > .hidden
                        for i in *.out; do echo "$i" >> .hidden; done
                        for i in *.log; do echo "$i" >> .hidden; done
                        for i in *.aux; do echo "$i" >> .hidden; done
                        for i in *.bbl; do echo "$i" >> .hidden; done
                        for i in *.blg; do echo "$i" >> .hidden; done
                        for i in *.dvi; do echo "$i" >> .hidden; done
                        for i in *.toc; do echo "$i" >> .hidden; done
                        for i in *.synctex.gz; do echo "$i" >> .hidden; done


                        Put this bash shell in your path, to do that put this line:



                        export PATH=$PATH:∼/scripts


                        into your ∼/.bashrc file
                        (in this example ~/scripts is the folder containing the bash shell above), this can be at the end of that file. Maybe you also have to run this file from the terminal, but this will ensure you can run this script anywhere, wherever you're keeping it.



                        Now you run this script in the terminal, while being in the directory needing cleaning and run the shell. That means that if the script is named tex.clean, you'd browse to the folder needing cleaning in terminal, enter



                        tex.clean


                        in the terminal, and browse to the file in the graphical file browser, and it should be clean :)



                        All the file with endings mentioned in the shell will be written to that directory's .hidden file. This means they will be hidden, but still usable :).



                        In nautilus (at least in fedora distributions) ctrl+h will show or hide hidden files.



                        P.S. I tried to have this as detailed as I could so people new to bash and command line like me could use this. I hope I succeeded :).






                        share|improve this answer





















                        • 5





                          You can avoid repetition of code by writing for i in *.{out,log,aux,bbl,blg,dvi,toc,synctex.gz}.

                          – Ryan Reich
                          Jul 6 '12 at 1:22











                        • I didn't know that writing file names to a file called .hidden will hide them like all other files that start with .. In which unices is that supported? (not Mac OS as far as I can tell)

                          – Matthew Leingang
                          Nov 20 '13 at 20:59













                        • It's not unix, only nautilus file manager (and possibly others, most certainly its forks nemo and caja) supports hiding via .hidden. If you browse that directory via ls you'll continue to see those files. Still, it's a fairly good solution to remove bothering files if you are a nautilus user.

                          – p91paul
                          Mar 30 '15 at 9:48


















                        6














                        For those like-minded as me, and running linux:



                        #! /bin/bash

                        echo -n > .hidden
                        for i in *.out; do echo "$i" >> .hidden; done
                        for i in *.log; do echo "$i" >> .hidden; done
                        for i in *.aux; do echo "$i" >> .hidden; done
                        for i in *.bbl; do echo "$i" >> .hidden; done
                        for i in *.blg; do echo "$i" >> .hidden; done
                        for i in *.dvi; do echo "$i" >> .hidden; done
                        for i in *.toc; do echo "$i" >> .hidden; done
                        for i in *.synctex.gz; do echo "$i" >> .hidden; done


                        Put this bash shell in your path, to do that put this line:



                        export PATH=$PATH:∼/scripts


                        into your ∼/.bashrc file
                        (in this example ~/scripts is the folder containing the bash shell above), this can be at the end of that file. Maybe you also have to run this file from the terminal, but this will ensure you can run this script anywhere, wherever you're keeping it.



                        Now you run this script in the terminal, while being in the directory needing cleaning and run the shell. That means that if the script is named tex.clean, you'd browse to the folder needing cleaning in terminal, enter



                        tex.clean


                        in the terminal, and browse to the file in the graphical file browser, and it should be clean :)



                        All the file with endings mentioned in the shell will be written to that directory's .hidden file. This means they will be hidden, but still usable :).



                        In nautilus (at least in fedora distributions) ctrl+h will show or hide hidden files.



                        P.S. I tried to have this as detailed as I could so people new to bash and command line like me could use this. I hope I succeeded :).






                        share|improve this answer





















                        • 5





                          You can avoid repetition of code by writing for i in *.{out,log,aux,bbl,blg,dvi,toc,synctex.gz}.

                          – Ryan Reich
                          Jul 6 '12 at 1:22











                        • I didn't know that writing file names to a file called .hidden will hide them like all other files that start with .. In which unices is that supported? (not Mac OS as far as I can tell)

                          – Matthew Leingang
                          Nov 20 '13 at 20:59













                        • It's not unix, only nautilus file manager (and possibly others, most certainly its forks nemo and caja) supports hiding via .hidden. If you browse that directory via ls you'll continue to see those files. Still, it's a fairly good solution to remove bothering files if you are a nautilus user.

                          – p91paul
                          Mar 30 '15 at 9:48
















                        6












                        6








                        6







                        For those like-minded as me, and running linux:



                        #! /bin/bash

                        echo -n > .hidden
                        for i in *.out; do echo "$i" >> .hidden; done
                        for i in *.log; do echo "$i" >> .hidden; done
                        for i in *.aux; do echo "$i" >> .hidden; done
                        for i in *.bbl; do echo "$i" >> .hidden; done
                        for i in *.blg; do echo "$i" >> .hidden; done
                        for i in *.dvi; do echo "$i" >> .hidden; done
                        for i in *.toc; do echo "$i" >> .hidden; done
                        for i in *.synctex.gz; do echo "$i" >> .hidden; done


                        Put this bash shell in your path, to do that put this line:



                        export PATH=$PATH:∼/scripts


                        into your ∼/.bashrc file
                        (in this example ~/scripts is the folder containing the bash shell above), this can be at the end of that file. Maybe you also have to run this file from the terminal, but this will ensure you can run this script anywhere, wherever you're keeping it.



                        Now you run this script in the terminal, while being in the directory needing cleaning and run the shell. That means that if the script is named tex.clean, you'd browse to the folder needing cleaning in terminal, enter



                        tex.clean


                        in the terminal, and browse to the file in the graphical file browser, and it should be clean :)



                        All the file with endings mentioned in the shell will be written to that directory's .hidden file. This means they will be hidden, but still usable :).



                        In nautilus (at least in fedora distributions) ctrl+h will show or hide hidden files.



                        P.S. I tried to have this as detailed as I could so people new to bash and command line like me could use this. I hope I succeeded :).






                        share|improve this answer















                        For those like-minded as me, and running linux:



                        #! /bin/bash

                        echo -n > .hidden
                        for i in *.out; do echo "$i" >> .hidden; done
                        for i in *.log; do echo "$i" >> .hidden; done
                        for i in *.aux; do echo "$i" >> .hidden; done
                        for i in *.bbl; do echo "$i" >> .hidden; done
                        for i in *.blg; do echo "$i" >> .hidden; done
                        for i in *.dvi; do echo "$i" >> .hidden; done
                        for i in *.toc; do echo "$i" >> .hidden; done
                        for i in *.synctex.gz; do echo "$i" >> .hidden; done


                        Put this bash shell in your path, to do that put this line:



                        export PATH=$PATH:∼/scripts


                        into your ∼/.bashrc file
                        (in this example ~/scripts is the folder containing the bash shell above), this can be at the end of that file. Maybe you also have to run this file from the terminal, but this will ensure you can run this script anywhere, wherever you're keeping it.



                        Now you run this script in the terminal, while being in the directory needing cleaning and run the shell. That means that if the script is named tex.clean, you'd browse to the folder needing cleaning in terminal, enter



                        tex.clean


                        in the terminal, and browse to the file in the graphical file browser, and it should be clean :)



                        All the file with endings mentioned in the shell will be written to that directory's .hidden file. This means they will be hidden, but still usable :).



                        In nautilus (at least in fedora distributions) ctrl+h will show or hide hidden files.



                        P.S. I tried to have this as detailed as I could so people new to bash and command line like me could use this. I hope I succeeded :).







                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited Aug 5 '16 at 9:09









                        Elmar Zander

                        1,1701215




                        1,1701215










                        answered Feb 14 '12 at 23:50









                        JóhannJóhann

                        1,07211126




                        1,07211126








                        • 5





                          You can avoid repetition of code by writing for i in *.{out,log,aux,bbl,blg,dvi,toc,synctex.gz}.

                          – Ryan Reich
                          Jul 6 '12 at 1:22











                        • I didn't know that writing file names to a file called .hidden will hide them like all other files that start with .. In which unices is that supported? (not Mac OS as far as I can tell)

                          – Matthew Leingang
                          Nov 20 '13 at 20:59













                        • It's not unix, only nautilus file manager (and possibly others, most certainly its forks nemo and caja) supports hiding via .hidden. If you browse that directory via ls you'll continue to see those files. Still, it's a fairly good solution to remove bothering files if you are a nautilus user.

                          – p91paul
                          Mar 30 '15 at 9:48
















                        • 5





                          You can avoid repetition of code by writing for i in *.{out,log,aux,bbl,blg,dvi,toc,synctex.gz}.

                          – Ryan Reich
                          Jul 6 '12 at 1:22











                        • I didn't know that writing file names to a file called .hidden will hide them like all other files that start with .. In which unices is that supported? (not Mac OS as far as I can tell)

                          – Matthew Leingang
                          Nov 20 '13 at 20:59













                        • It's not unix, only nautilus file manager (and possibly others, most certainly its forks nemo and caja) supports hiding via .hidden. If you browse that directory via ls you'll continue to see those files. Still, it's a fairly good solution to remove bothering files if you are a nautilus user.

                          – p91paul
                          Mar 30 '15 at 9:48










                        5




                        5





                        You can avoid repetition of code by writing for i in *.{out,log,aux,bbl,blg,dvi,toc,synctex.gz}.

                        – Ryan Reich
                        Jul 6 '12 at 1:22





                        You can avoid repetition of code by writing for i in *.{out,log,aux,bbl,blg,dvi,toc,synctex.gz}.

                        – Ryan Reich
                        Jul 6 '12 at 1:22













                        I didn't know that writing file names to a file called .hidden will hide them like all other files that start with .. In which unices is that supported? (not Mac OS as far as I can tell)

                        – Matthew Leingang
                        Nov 20 '13 at 20:59







                        I didn't know that writing file names to a file called .hidden will hide them like all other files that start with .. In which unices is that supported? (not Mac OS as far as I can tell)

                        – Matthew Leingang
                        Nov 20 '13 at 20:59















                        It's not unix, only nautilus file manager (and possibly others, most certainly its forks nemo and caja) supports hiding via .hidden. If you browse that directory via ls you'll continue to see those files. Still, it's a fairly good solution to remove bothering files if you are a nautilus user.

                        – p91paul
                        Mar 30 '15 at 9:48







                        It's not unix, only nautilus file manager (and possibly others, most certainly its forks nemo and caja) supports hiding via .hidden. If you browse that directory via ls you'll continue to see those files. Still, it's a fairly good solution to remove bothering files if you are a nautilus user.

                        – p91paul
                        Mar 30 '15 at 9:48













                        4














                        Though this is an older question, I want to contribute something that might help people who love clean workspaces. I created a shell script that deletes all junk files at once. It will work on Mac and Linux; with some adjustments Windows should be possible too. Download the file "cleanlatexjunk.sh" from my repository and follow the instructions:



                        https://github.com/cgraumann/LatexUtils




                        1. Open Preferences/Build in TexStudio

                        2. Select Advanced options at the bottom

                        3. Add a new user command with the name cleanjunk

                        4. As the command, enter:

                          "/PATH/TO/SCRIPT/cleanlatexjunk.sh" -fp ?me ?a)

                          and change /PATH/TO/SCRIPT/ accordingly

                        5. In the meta-command for Build & View add | txs:///cleanjunk at the end


                        Important: As described by people before, the "junk" files are actually needed. Therefore you should also adjust your build workflow to do multiple compiles in a row. This assures that all TOCs and links are rendered correctly. After two or three compile runs, you can safely use my script as described.



                        Now every build & view execution should result in a clean workspace :-)






                        share|improve this answer
























                        • Welcome to TeX.SX!

                          – Heiko Oberdiek
                          Jun 8 '15 at 14:27
















                        4














                        Though this is an older question, I want to contribute something that might help people who love clean workspaces. I created a shell script that deletes all junk files at once. It will work on Mac and Linux; with some adjustments Windows should be possible too. Download the file "cleanlatexjunk.sh" from my repository and follow the instructions:



                        https://github.com/cgraumann/LatexUtils




                        1. Open Preferences/Build in TexStudio

                        2. Select Advanced options at the bottom

                        3. Add a new user command with the name cleanjunk

                        4. As the command, enter:

                          "/PATH/TO/SCRIPT/cleanlatexjunk.sh" -fp ?me ?a)

                          and change /PATH/TO/SCRIPT/ accordingly

                        5. In the meta-command for Build & View add | txs:///cleanjunk at the end


                        Important: As described by people before, the "junk" files are actually needed. Therefore you should also adjust your build workflow to do multiple compiles in a row. This assures that all TOCs and links are rendered correctly. After two or three compile runs, you can safely use my script as described.



                        Now every build & view execution should result in a clean workspace :-)






                        share|improve this answer
























                        • Welcome to TeX.SX!

                          – Heiko Oberdiek
                          Jun 8 '15 at 14:27














                        4












                        4








                        4







                        Though this is an older question, I want to contribute something that might help people who love clean workspaces. I created a shell script that deletes all junk files at once. It will work on Mac and Linux; with some adjustments Windows should be possible too. Download the file "cleanlatexjunk.sh" from my repository and follow the instructions:



                        https://github.com/cgraumann/LatexUtils




                        1. Open Preferences/Build in TexStudio

                        2. Select Advanced options at the bottom

                        3. Add a new user command with the name cleanjunk

                        4. As the command, enter:

                          "/PATH/TO/SCRIPT/cleanlatexjunk.sh" -fp ?me ?a)

                          and change /PATH/TO/SCRIPT/ accordingly

                        5. In the meta-command for Build & View add | txs:///cleanjunk at the end


                        Important: As described by people before, the "junk" files are actually needed. Therefore you should also adjust your build workflow to do multiple compiles in a row. This assures that all TOCs and links are rendered correctly. After two or three compile runs, you can safely use my script as described.



                        Now every build & view execution should result in a clean workspace :-)






                        share|improve this answer













                        Though this is an older question, I want to contribute something that might help people who love clean workspaces. I created a shell script that deletes all junk files at once. It will work on Mac and Linux; with some adjustments Windows should be possible too. Download the file "cleanlatexjunk.sh" from my repository and follow the instructions:



                        https://github.com/cgraumann/LatexUtils




                        1. Open Preferences/Build in TexStudio

                        2. Select Advanced options at the bottom

                        3. Add a new user command with the name cleanjunk

                        4. As the command, enter:

                          "/PATH/TO/SCRIPT/cleanlatexjunk.sh" -fp ?me ?a)

                          and change /PATH/TO/SCRIPT/ accordingly

                        5. In the meta-command for Build & View add | txs:///cleanjunk at the end


                        Important: As described by people before, the "junk" files are actually needed. Therefore you should also adjust your build workflow to do multiple compiles in a row. This assures that all TOCs and links are rendered correctly. After two or three compile runs, you can safely use my script as described.



                        Now every build & view execution should result in a clean workspace :-)







                        share|improve this answer












                        share|improve this answer



                        share|improve this answer










                        answered Jun 8 '15 at 14:01









                        Captain AhabCaptain Ahab

                        412




                        412













                        • Welcome to TeX.SX!

                          – Heiko Oberdiek
                          Jun 8 '15 at 14:27



















                        • Welcome to TeX.SX!

                          – Heiko Oberdiek
                          Jun 8 '15 at 14:27

















                        Welcome to TeX.SX!

                        – Heiko Oberdiek
                        Jun 8 '15 at 14:27





                        Welcome to TeX.SX!

                        – Heiko Oberdiek
                        Jun 8 '15 at 14:27











                        2














                        # write a makefile and remove all of the unwanted files after compilation.   
                        # change your folder structure as you see fit.
                        # Folder structure
                        DOCDIR = doc/
                        TEXDIR = doc/tex/

                        # The compiler and the -output-directory flag
                        TCC = pdflatex
                        TEXFLAGS = -output-directory

                        documentation:
                        $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename1.tex
                        $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename2.tex
                        $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename3.tex
                        rm -f $(DOCDIR)*.log
                        rm -f $(DOCDIR)*.aux
                        rm -f $(DOCDIR)*.toc
                        rm -f *.pdf
                        rm -f *.aux
                        rm -f *.toc
                        rm -f *.log

                        # Though if using this method you have to be careful with the image paths in
                        # your tex source file. They're taken from the makefile directory.

                        # To use the file type >> make documentation << in a terminal

                        # You can also do it like this

                        documentation:
                        $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename1.tex
                        $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename2.tex
                        $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename3.tex

                        clean:
                        rm -f $(DOCDIR)*.log
                        rm -f $(DOCDIR)*.aux
                        rm -f $(DOCDIR)*.toc
                        rm -f *.pdf
                        rm -f *.aux
                        rm -f *.toc
                        rm -f *.log

                        # now >> make clean documentation << outputs with no crappy files
                        # and >> make documentation << outputs with the crappy files
                        # and >> make clean << cleans all the crappy files.





                        share|improve this answer






























                          2














                          # write a makefile and remove all of the unwanted files after compilation.   
                          # change your folder structure as you see fit.
                          # Folder structure
                          DOCDIR = doc/
                          TEXDIR = doc/tex/

                          # The compiler and the -output-directory flag
                          TCC = pdflatex
                          TEXFLAGS = -output-directory

                          documentation:
                          $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename1.tex
                          $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename2.tex
                          $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename3.tex
                          rm -f $(DOCDIR)*.log
                          rm -f $(DOCDIR)*.aux
                          rm -f $(DOCDIR)*.toc
                          rm -f *.pdf
                          rm -f *.aux
                          rm -f *.toc
                          rm -f *.log

                          # Though if using this method you have to be careful with the image paths in
                          # your tex source file. They're taken from the makefile directory.

                          # To use the file type >> make documentation << in a terminal

                          # You can also do it like this

                          documentation:
                          $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename1.tex
                          $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename2.tex
                          $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename3.tex

                          clean:
                          rm -f $(DOCDIR)*.log
                          rm -f $(DOCDIR)*.aux
                          rm -f $(DOCDIR)*.toc
                          rm -f *.pdf
                          rm -f *.aux
                          rm -f *.toc
                          rm -f *.log

                          # now >> make clean documentation << outputs with no crappy files
                          # and >> make documentation << outputs with the crappy files
                          # and >> make clean << cleans all the crappy files.





                          share|improve this answer




























                            2












                            2








                            2







                            # write a makefile and remove all of the unwanted files after compilation.   
                            # change your folder structure as you see fit.
                            # Folder structure
                            DOCDIR = doc/
                            TEXDIR = doc/tex/

                            # The compiler and the -output-directory flag
                            TCC = pdflatex
                            TEXFLAGS = -output-directory

                            documentation:
                            $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename1.tex
                            $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename2.tex
                            $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename3.tex
                            rm -f $(DOCDIR)*.log
                            rm -f $(DOCDIR)*.aux
                            rm -f $(DOCDIR)*.toc
                            rm -f *.pdf
                            rm -f *.aux
                            rm -f *.toc
                            rm -f *.log

                            # Though if using this method you have to be careful with the image paths in
                            # your tex source file. They're taken from the makefile directory.

                            # To use the file type >> make documentation << in a terminal

                            # You can also do it like this

                            documentation:
                            $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename1.tex
                            $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename2.tex
                            $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename3.tex

                            clean:
                            rm -f $(DOCDIR)*.log
                            rm -f $(DOCDIR)*.aux
                            rm -f $(DOCDIR)*.toc
                            rm -f *.pdf
                            rm -f *.aux
                            rm -f *.toc
                            rm -f *.log

                            # now >> make clean documentation << outputs with no crappy files
                            # and >> make documentation << outputs with the crappy files
                            # and >> make clean << cleans all the crappy files.





                            share|improve this answer















                            # write a makefile and remove all of the unwanted files after compilation.   
                            # change your folder structure as you see fit.
                            # Folder structure
                            DOCDIR = doc/
                            TEXDIR = doc/tex/

                            # The compiler and the -output-directory flag
                            TCC = pdflatex
                            TEXFLAGS = -output-directory

                            documentation:
                            $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename1.tex
                            $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename2.tex
                            $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename3.tex
                            rm -f $(DOCDIR)*.log
                            rm -f $(DOCDIR)*.aux
                            rm -f $(DOCDIR)*.toc
                            rm -f *.pdf
                            rm -f *.aux
                            rm -f *.toc
                            rm -f *.log

                            # Though if using this method you have to be careful with the image paths in
                            # your tex source file. They're taken from the makefile directory.

                            # To use the file type >> make documentation << in a terminal

                            # You can also do it like this

                            documentation:
                            $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename1.tex
                            $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename2.tex
                            $(TCC) $(TEXFLAGS) $(DOCDIR) $(TEXDIR)filename3.tex

                            clean:
                            rm -f $(DOCDIR)*.log
                            rm -f $(DOCDIR)*.aux
                            rm -f $(DOCDIR)*.toc
                            rm -f *.pdf
                            rm -f *.aux
                            rm -f *.toc
                            rm -f *.log

                            # now >> make clean documentation << outputs with no crappy files
                            # and >> make documentation << outputs with the crappy files
                            # and >> make clean << cleans all the crappy files.






                            share|improve this answer














                            share|improve this answer



                            share|improve this answer








                            edited Jun 24 '12 at 23:30









                            doncherry

                            34.9k23135208




                            34.9k23135208










                            answered Jun 11 '12 at 9:40









                            mehmeh

                            212




                            212























                                2














                                Going back to why so many extra files (and why the C compiler doesn’t – apparently – do this): C is a language designed for single-pass compilation. Names must be defined before used. LaTeX isn’t. In a world with tight memory, the way to handle this is to use two passes, storing information needed for the second pass on the way through.



                                In today’s world with big memories, this is not entirely necessary. A LaTeX compiler could in principle store everything needed in internal tables and go back and patch in information as it became available.



                                If you really want to manage this properly, you need to work out how to use a makefile (or other similar build manager) to decide automatically when a second run is needed (some cases are obvious, like when you change your bibliography, others less so). Read this if you want to find out about Makefiles and LaTeX in detail.






                                share|improve this answer



















                                • 1





                                  "C is a language designed for single-pass compilation." False. C uses multiple passes (preprocessing, compiling, maybe some optimizing, linking, maybe more optimizing) and a C compiler may even choose to dump 5 million files into pwd that are useless after the passes are finished. Most compilers don't unless you tell them to.

                                  – Jonathan Baldwin
                                  Nov 7 '13 at 0:42
















                                2














                                Going back to why so many extra files (and why the C compiler doesn’t – apparently – do this): C is a language designed for single-pass compilation. Names must be defined before used. LaTeX isn’t. In a world with tight memory, the way to handle this is to use two passes, storing information needed for the second pass on the way through.



                                In today’s world with big memories, this is not entirely necessary. A LaTeX compiler could in principle store everything needed in internal tables and go back and patch in information as it became available.



                                If you really want to manage this properly, you need to work out how to use a makefile (or other similar build manager) to decide automatically when a second run is needed (some cases are obvious, like when you change your bibliography, others less so). Read this if you want to find out about Makefiles and LaTeX in detail.






                                share|improve this answer



















                                • 1





                                  "C is a language designed for single-pass compilation." False. C uses multiple passes (preprocessing, compiling, maybe some optimizing, linking, maybe more optimizing) and a C compiler may even choose to dump 5 million files into pwd that are useless after the passes are finished. Most compilers don't unless you tell them to.

                                  – Jonathan Baldwin
                                  Nov 7 '13 at 0:42














                                2












                                2








                                2







                                Going back to why so many extra files (and why the C compiler doesn’t – apparently – do this): C is a language designed for single-pass compilation. Names must be defined before used. LaTeX isn’t. In a world with tight memory, the way to handle this is to use two passes, storing information needed for the second pass on the way through.



                                In today’s world with big memories, this is not entirely necessary. A LaTeX compiler could in principle store everything needed in internal tables and go back and patch in information as it became available.



                                If you really want to manage this properly, you need to work out how to use a makefile (or other similar build manager) to decide automatically when a second run is needed (some cases are obvious, like when you change your bibliography, others less so). Read this if you want to find out about Makefiles and LaTeX in detail.






                                share|improve this answer













                                Going back to why so many extra files (and why the C compiler doesn’t – apparently – do this): C is a language designed for single-pass compilation. Names must be defined before used. LaTeX isn’t. In a world with tight memory, the way to handle this is to use two passes, storing information needed for the second pass on the way through.



                                In today’s world with big memories, this is not entirely necessary. A LaTeX compiler could in principle store everything needed in internal tables and go back and patch in information as it became available.



                                If you really want to manage this properly, you need to work out how to use a makefile (or other similar build manager) to decide automatically when a second run is needed (some cases are obvious, like when you change your bibliography, others less so). Read this if you want to find out about Makefiles and LaTeX in detail.







                                share|improve this answer












                                share|improve this answer



                                share|improve this answer










                                answered Jul 18 '13 at 7:08









                                PhilipMPhilipM

                                394




                                394








                                • 1





                                  "C is a language designed for single-pass compilation." False. C uses multiple passes (preprocessing, compiling, maybe some optimizing, linking, maybe more optimizing) and a C compiler may even choose to dump 5 million files into pwd that are useless after the passes are finished. Most compilers don't unless you tell them to.

                                  – Jonathan Baldwin
                                  Nov 7 '13 at 0:42














                                • 1





                                  "C is a language designed for single-pass compilation." False. C uses multiple passes (preprocessing, compiling, maybe some optimizing, linking, maybe more optimizing) and a C compiler may even choose to dump 5 million files into pwd that are useless after the passes are finished. Most compilers don't unless you tell them to.

                                  – Jonathan Baldwin
                                  Nov 7 '13 at 0:42








                                1




                                1





                                "C is a language designed for single-pass compilation." False. C uses multiple passes (preprocessing, compiling, maybe some optimizing, linking, maybe more optimizing) and a C compiler may even choose to dump 5 million files into pwd that are useless after the passes are finished. Most compilers don't unless you tell them to.

                                – Jonathan Baldwin
                                Nov 7 '13 at 0:42





                                "C is a language designed for single-pass compilation." False. C uses multiple passes (preprocessing, compiling, maybe some optimizing, linking, maybe more optimizing) and a C compiler may even choose to dump 5 million files into pwd that are useless after the passes are finished. Most compilers don't unless you tell them to.

                                – Jonathan Baldwin
                                Nov 7 '13 at 0:42











                                2














                                For Mac OS X 18.* users (I'm using Mountain Lion) the .hidden file list does not appear to work any more for Finder. An alternative to the previous script would be



                                for i in *.{out,log,aux,toc,bbl,dvi,blg,synctex.gz};
                                do chflags hidden $i;
                                done


                                which also works in some flavors of Linux.






                                share|improve this answer






























                                  2














                                  For Mac OS X 18.* users (I'm using Mountain Lion) the .hidden file list does not appear to work any more for Finder. An alternative to the previous script would be



                                  for i in *.{out,log,aux,toc,bbl,dvi,blg,synctex.gz};
                                  do chflags hidden $i;
                                  done


                                  which also works in some flavors of Linux.






                                  share|improve this answer




























                                    2












                                    2








                                    2







                                    For Mac OS X 18.* users (I'm using Mountain Lion) the .hidden file list does not appear to work any more for Finder. An alternative to the previous script would be



                                    for i in *.{out,log,aux,toc,bbl,dvi,blg,synctex.gz};
                                    do chflags hidden $i;
                                    done


                                    which also works in some flavors of Linux.






                                    share|improve this answer















                                    For Mac OS X 18.* users (I'm using Mountain Lion) the .hidden file list does not appear to work any more for Finder. An alternative to the previous script would be



                                    for i in *.{out,log,aux,toc,bbl,dvi,blg,synctex.gz};
                                    do chflags hidden $i;
                                    done


                                    which also works in some flavors of Linux.







                                    share|improve this answer














                                    share|improve this answer



                                    share|improve this answer








                                    edited Sep 15 '14 at 21:20

























                                    answered Feb 2 '13 at 5:38









                                    Ioannis FilippidisIoannis Filippidis

                                    466421




                                    466421























                                        1














                                        There's still another option, you can merge the Clean button and the close button in TexMaker so when you close all the auxiliary files are deleted. This way you don't have to remember to Clean all the time yet you can still use the auxiliary files as long as you don't close.



                                        This can be done downloading the sourcecode. The important file is texmaker.cpp and the processes are CleanAll and fileClose






                                        share|improve this answer
























                                        • This is a feature in Configure Texmaker > Commands > Launch the "Clean" tool when exiting Texmaker

                                          – qwr
                                          Oct 17 '16 at 5:10
















                                        1














                                        There's still another option, you can merge the Clean button and the close button in TexMaker so when you close all the auxiliary files are deleted. This way you don't have to remember to Clean all the time yet you can still use the auxiliary files as long as you don't close.



                                        This can be done downloading the sourcecode. The important file is texmaker.cpp and the processes are CleanAll and fileClose






                                        share|improve this answer
























                                        • This is a feature in Configure Texmaker > Commands > Launch the "Clean" tool when exiting Texmaker

                                          – qwr
                                          Oct 17 '16 at 5:10














                                        1












                                        1








                                        1







                                        There's still another option, you can merge the Clean button and the close button in TexMaker so when you close all the auxiliary files are deleted. This way you don't have to remember to Clean all the time yet you can still use the auxiliary files as long as you don't close.



                                        This can be done downloading the sourcecode. The important file is texmaker.cpp and the processes are CleanAll and fileClose






                                        share|improve this answer













                                        There's still another option, you can merge the Clean button and the close button in TexMaker so when you close all the auxiliary files are deleted. This way you don't have to remember to Clean all the time yet you can still use the auxiliary files as long as you don't close.



                                        This can be done downloading the sourcecode. The important file is texmaker.cpp and the processes are CleanAll and fileClose







                                        share|improve this answer












                                        share|improve this answer



                                        share|improve this answer










                                        answered Jul 5 '12 at 15:25









                                        Gabriel FurstenheimGabriel Furstenheim

                                        1112




                                        1112













                                        • This is a feature in Configure Texmaker > Commands > Launch the "Clean" tool when exiting Texmaker

                                          – qwr
                                          Oct 17 '16 at 5:10



















                                        • This is a feature in Configure Texmaker > Commands > Launch the "Clean" tool when exiting Texmaker

                                          – qwr
                                          Oct 17 '16 at 5:10

















                                        This is a feature in Configure Texmaker > Commands > Launch the "Clean" tool when exiting Texmaker

                                        – qwr
                                        Oct 17 '16 at 5:10





                                        This is a feature in Configure Texmaker > Commands > Launch the "Clean" tool when exiting Texmaker

                                        – qwr
                                        Oct 17 '16 at 5:10











                                        1














                                        Texmaker includes an option to "use a build directory for output files" which kind of does the trick.



                                        If you enable this setting Texmaker creates a 'build' folder in the same directory as the document .tex file. It automatically cleans the old output and outputs into the build folder instead.



                                        The setting works well but isn't perfect. For example I've found that after adding a new citation to the document Bibtex complained when it couldn't find the .aux file. I had to copy the aux file back out of the build folder to compile the document. I'm not sure if there's a way to fix that yet.






                                        share|improve this answer






























                                          1














                                          Texmaker includes an option to "use a build directory for output files" which kind of does the trick.



                                          If you enable this setting Texmaker creates a 'build' folder in the same directory as the document .tex file. It automatically cleans the old output and outputs into the build folder instead.



                                          The setting works well but isn't perfect. For example I've found that after adding a new citation to the document Bibtex complained when it couldn't find the .aux file. I had to copy the aux file back out of the build folder to compile the document. I'm not sure if there's a way to fix that yet.






                                          share|improve this answer




























                                            1












                                            1








                                            1







                                            Texmaker includes an option to "use a build directory for output files" which kind of does the trick.



                                            If you enable this setting Texmaker creates a 'build' folder in the same directory as the document .tex file. It automatically cleans the old output and outputs into the build folder instead.



                                            The setting works well but isn't perfect. For example I've found that after adding a new citation to the document Bibtex complained when it couldn't find the .aux file. I had to copy the aux file back out of the build folder to compile the document. I'm not sure if there's a way to fix that yet.






                                            share|improve this answer















                                            Texmaker includes an option to "use a build directory for output files" which kind of does the trick.



                                            If you enable this setting Texmaker creates a 'build' folder in the same directory as the document .tex file. It automatically cleans the old output and outputs into the build folder instead.



                                            The setting works well but isn't perfect. For example I've found that after adding a new citation to the document Bibtex complained when it couldn't find the .aux file. I had to copy the aux file back out of the build folder to compile the document. I'm not sure if there's a way to fix that yet.







                                            share|improve this answer














                                            share|improve this answer



                                            share|improve this answer








                                            edited Mar 30 '14 at 14:45

























                                            answered Mar 30 '14 at 10:36









                                            swissswiss

                                            213




                                            213























                                                1














                                                These files are needed but yes, there's no need to have them at the same path. Use this bash script to avoid cluttering of the folder containing your .tex file:



                                                # plcl: pdflatex clean
                                                infile=`readlink -f "$1"`
                                                inpath=`dirname "$infile"`
                                                tmpath="/tmp/pdflatex`echo "$inpath" | sed -e 's///-/g'`"

                                                mkdir "$tmpath"
                                                pdflatex -output-directory "$tmpath" "$1"
                                                mv "$tmpath"/*pdf "$inpath"


                                                This requires bash and sed.






                                                share|improve this answer




























                                                  1














                                                  These files are needed but yes, there's no need to have them at the same path. Use this bash script to avoid cluttering of the folder containing your .tex file:



                                                  # plcl: pdflatex clean
                                                  infile=`readlink -f "$1"`
                                                  inpath=`dirname "$infile"`
                                                  tmpath="/tmp/pdflatex`echo "$inpath" | sed -e 's///-/g'`"

                                                  mkdir "$tmpath"
                                                  pdflatex -output-directory "$tmpath" "$1"
                                                  mv "$tmpath"/*pdf "$inpath"


                                                  This requires bash and sed.






                                                  share|improve this answer


























                                                    1












                                                    1








                                                    1







                                                    These files are needed but yes, there's no need to have them at the same path. Use this bash script to avoid cluttering of the folder containing your .tex file:



                                                    # plcl: pdflatex clean
                                                    infile=`readlink -f "$1"`
                                                    inpath=`dirname "$infile"`
                                                    tmpath="/tmp/pdflatex`echo "$inpath" | sed -e 's///-/g'`"

                                                    mkdir "$tmpath"
                                                    pdflatex -output-directory "$tmpath" "$1"
                                                    mv "$tmpath"/*pdf "$inpath"


                                                    This requires bash and sed.






                                                    share|improve this answer













                                                    These files are needed but yes, there's no need to have them at the same path. Use this bash script to avoid cluttering of the folder containing your .tex file:



                                                    # plcl: pdflatex clean
                                                    infile=`readlink -f "$1"`
                                                    inpath=`dirname "$infile"`
                                                    tmpath="/tmp/pdflatex`echo "$inpath" | sed -e 's///-/g'`"

                                                    mkdir "$tmpath"
                                                    pdflatex -output-directory "$tmpath" "$1"
                                                    mv "$tmpath"/*pdf "$inpath"


                                                    This requires bash and sed.







                                                    share|improve this answer












                                                    share|improve this answer



                                                    share|improve this answer










                                                    answered May 19 '16 at 12:17









                                                    qubodupqubodup

                                                    1356




                                                    1356























                                                        1














                                                        The LaTeX build wrapper ltx2any may be a solution. This does not prevent the creation of all the auxiliary files, but places them in another directory, which you can specify



                                                        ltx2any -t path_where_you_want_the_auxiliary_files_to_go filename.tex 


                                                        This path can very well be a tmp folder.



                                                        For more options, see ltx2any --help.






                                                        share|improve this answer




























                                                          1














                                                          The LaTeX build wrapper ltx2any may be a solution. This does not prevent the creation of all the auxiliary files, but places them in another directory, which you can specify



                                                          ltx2any -t path_where_you_want_the_auxiliary_files_to_go filename.tex 


                                                          This path can very well be a tmp folder.



                                                          For more options, see ltx2any --help.






                                                          share|improve this answer


























                                                            1












                                                            1








                                                            1







                                                            The LaTeX build wrapper ltx2any may be a solution. This does not prevent the creation of all the auxiliary files, but places them in another directory, which you can specify



                                                            ltx2any -t path_where_you_want_the_auxiliary_files_to_go filename.tex 


                                                            This path can very well be a tmp folder.



                                                            For more options, see ltx2any --help.






                                                            share|improve this answer













                                                            The LaTeX build wrapper ltx2any may be a solution. This does not prevent the creation of all the auxiliary files, but places them in another directory, which you can specify



                                                            ltx2any -t path_where_you_want_the_auxiliary_files_to_go filename.tex 


                                                            This path can very well be a tmp folder.



                                                            For more options, see ltx2any --help.







                                                            share|improve this answer












                                                            share|improve this answer



                                                            share|improve this answer










                                                            answered Jul 2 '16 at 14:05









                                                            samcartersamcarter

                                                            88.6k799284




                                                            88.6k799284























                                                                0














                                                                Just do it: It's dirty but useful.



                                                                cd /usr/bin && mv pdflatex __backup_real_pdflatex
                                                                vim pdflatex


                                                                #!/bin/bash

                                                                fname="$1"
                                                                /usr/bin/__backup_real_pdflatex $@ && rm -f "$fname."{log,nav,out,aux,toc,snm}
                                                                exit $?


                                                                WARNING: The script above is not tested even once!!





                                                                share








                                                                New contributor




                                                                Recolic Keghart is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                Check out our Code of Conduct.

























                                                                  0














                                                                  Just do it: It's dirty but useful.



                                                                  cd /usr/bin && mv pdflatex __backup_real_pdflatex
                                                                  vim pdflatex


                                                                  #!/bin/bash

                                                                  fname="$1"
                                                                  /usr/bin/__backup_real_pdflatex $@ && rm -f "$fname."{log,nav,out,aux,toc,snm}
                                                                  exit $?


                                                                  WARNING: The script above is not tested even once!!





                                                                  share








                                                                  New contributor




                                                                  Recolic Keghart is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                  Check out our Code of Conduct.























                                                                    0












                                                                    0








                                                                    0







                                                                    Just do it: It's dirty but useful.



                                                                    cd /usr/bin && mv pdflatex __backup_real_pdflatex
                                                                    vim pdflatex


                                                                    #!/bin/bash

                                                                    fname="$1"
                                                                    /usr/bin/__backup_real_pdflatex $@ && rm -f "$fname."{log,nav,out,aux,toc,snm}
                                                                    exit $?


                                                                    WARNING: The script above is not tested even once!!





                                                                    share








                                                                    New contributor




                                                                    Recolic Keghart is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                    Check out our Code of Conduct.










                                                                    Just do it: It's dirty but useful.



                                                                    cd /usr/bin && mv pdflatex __backup_real_pdflatex
                                                                    vim pdflatex


                                                                    #!/bin/bash

                                                                    fname="$1"
                                                                    /usr/bin/__backup_real_pdflatex $@ && rm -f "$fname."{log,nav,out,aux,toc,snm}
                                                                    exit $?


                                                                    WARNING: The script above is not tested even once!!






                                                                    share








                                                                    New contributor




                                                                    Recolic Keghart is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                    Check out our Code of Conduct.








                                                                    share


                                                                    share






                                                                    New contributor




                                                                    Recolic Keghart is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                    Check out our Code of Conduct.









                                                                    answered 4 mins ago









                                                                    Recolic KeghartRecolic Keghart

                                                                    1




                                                                    1




                                                                    New contributor




                                                                    Recolic Keghart is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                    Check out our Code of Conduct.





                                                                    New contributor





                                                                    Recolic Keghart is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                    Check out our Code of Conduct.






                                                                    Recolic Keghart is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                    Check out our Code of Conduct.






























                                                                        draft saved

                                                                        draft discarded




















































                                                                        Thanks for contributing an answer to TeX - LaTeX Stack Exchange!


                                                                        • Please be sure to answer the question. Provide details and share your research!

                                                                        But avoid



                                                                        • Asking for help, clarification, or responding to other answers.

                                                                        • Making statements based on opinion; back them up with references or personal experience.


                                                                        To learn more, see our tips on writing great answers.




                                                                        draft saved


                                                                        draft discarded














                                                                        StackExchange.ready(
                                                                        function () {
                                                                        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f11123%2fprevent-pdflatex-from-writing-a-bunch-of-files%23new-answer', 'question_page');
                                                                        }
                                                                        );

                                                                        Post as a guest















                                                                        Required, but never shown





















































                                                                        Required, but never shown














                                                                        Required, but never shown












                                                                        Required, but never shown







                                                                        Required, but never shown

































                                                                        Required, but never shown














                                                                        Required, but never shown












                                                                        Required, but never shown







                                                                        Required, but never shown







                                                                        Popular posts from this blog

                                                                        Accessing regular linux commands in Huawei's Dopra Linux

                                                                        Can't connect RFCOMM socket: Host is down

                                                                        Kernel panic - not syncing: Fatal Exception in Interrupt