I have asked a previous question about how to manage all the files generated when my LaTeX files are compiled but the approach in the answer I accepted is still unsatisfactory for the many small documents I generate.

I realize the LaTeX needs all the files it generates so I can't prevent their creation.

However is there a way to configure pdflatex to make all but the .tex and .pdf files hidden files (i.e., preceded by .)?

(Edit: The two main systems that I use are tex live on Ubuntu Linux and BasicTeX on OS X)

  • 4
    You can define an -output-directory directive and point out to a hidden folder to store the auxilliary files but I am not knowledgeable enough to tell whether it would be discoverable by the system.
    – percusse
    Commented Dec 21, 2012 at 1:51
  • 4
    Which OS? Preceding files on Windows 7 with a . doesn’t hide them, though attrib +H \jobname.\ext does set the “hidden” flag. Commented Dec 21, 2012 at 2:06
  • 1
    Would you be satisfied with a scripted solution, i.e. a pre- and post-processing .bat file, or a special Editor setup that does something before and after calling pdflatex? Commented Dec 21, 2012 at 2:17
  • @Qrrbrbirlbel I don't have a lot of scripting experience but if it is something that could be understood by a relative novice and it works, then absolutely.
    – DQdlM
    Commented Dec 21, 2012 at 2:57
  • I recommend Texpad on Mac OS X or iOS. It takes care of file management for you and you can concentrate on writing. Also: BibDesk for Mac OS and PocketBib for iOS. Commented Dec 26, 2012 at 10:05

8 Answers 8


This may be a job easily done with the help of your tex editor. With winedt, it is done like this (for miktex only ):

Go to winedt menu Options ---> Execution Modes. In the window that opens choose TeX Options:

enter image description here

Make the modifications as shown in the picture. Give OK and come out. Now all the auxiliary files will be stored inside a folder TeXAux inside your main folder. If you uncheck the box, the directory TeXAux will be created if it doesn't exist already. Hence your main directory will not get cluttered.

Similar options may be available for other editors also, but unfortunately I don't have much idea about them :-(


Following a personal mail from Karl Koeller (who is a great contributor for winedt and its macros):

I just wanted you to notice that WinEdt (starting with the latest 6 builds) uses its own algorithm (written by myself) to manage auxiliary files in TeXAux folder. In other words, it does not use --aux-directory command line switch provided by some miktex applications (see 'Auxiliary folder' in the WinEdt manual index).

That means that this feature does NOT depend on the TeX System you use. TeX Live users can take advantage of this feature, too.

Hence, this feature is available for texlive also from winedt 6 onwards.


Go to Options ---> Configure Texmaker to get the window:

enter image description here

Check the box as shown in the picture, press OK and come out. Now ALL output files (unfortunately including pdf file) will be stored inside a folder build inside the main folder.

Easy cleaning of auxiliary files

If every thing boils down to cleaning the auxiliary files, one may settle with Arara. It's excellent manual is a worth reading for details. You have to add the clean directive as

% arara: clean: {files: [yourfile.aux, yourfile.idx, yourfile.ilg, yourfile.ind, yourfile.log, yourfile.bbl, yourfile.bcf, yourfile.ist, yourfile.blg, yourfile.run.xml]}

You can add the files to be cleaned at your will. A normal set of directive may look like:

% arara: pdflatex: {synctex: yes}
% arara: makeindex
% arara: biber
% arara: pdflatex: {synctex: yes}
% arara: pdflatex: {synctex: yes}
% arara: clean: {files: [yourfile.aux, yourfile.idx, yourfile.ilg, yourfile.ind, yourfile.log, yourfile.bbl, yourfile.bcf, yourfile.ist, yourfile.blg, yourfile.run.xml]}

Then compile your document by issuing arara yourfile. You have to make sure that the arara is installed and is in system path.

  • Eclipse + texlipse also has this feature. It is a very nice editor as well -:)
    – rowman
    Commented Dec 25, 2012 at 20:16
  • Note, however, that this is a MikTeX-only (hence, Windows-only) solution, as only the MikTeX version of pdflatex supports the -aux-directory option that is used at the bottom.
    – Daniel
    Commented Dec 26, 2012 at 12:20
  • Right, my point is that this very useful feature (-aux-directory) is more TeX-distro than an editor-specific. IMHO that should be clarified in the answer.
    – Daniel
    Commented Dec 26, 2012 at 12:34
  • Latexila and Kile editors clean auxiliary files automatically and Gummi have a menu to "Clean Bluid Files".
    – Fran
    Commented Dec 29, 2012 at 11:04
  • @Daniel Please see the addendum. :-)
    – user11232
    Commented Mar 14, 2013 at 13:06

Apparently there's a not-very-well-known feature of Nautilus (which you might be using if you use Ubuntu;)) where you put a list of filenames (no wildcards!), one per line, in a file called .hidden in some directory; then Nautilus won't display these files (you may need to refresh the view in Nautilus for this to take effect). Then, it is a question of some simple scripting to create this file. For instance, something like

# make LaTeX intermediate files in the current directory hidden in Nautilus 
ls *.aux *.log *.toc &> /dev/null >> .hidden
sort .hidden | uniq > .hidden-new
mv .hidden-new .hidden

Now you can call such a script e.g. after you process any file with TeX.

(Important notice: you may use the script presented here, but only at your own risk - my bash-fu is much weaker than my TeX-fu;)!)

Also Emacs (which I'm using - there's no alternative anyway, since it is the single best text editor in existence) has a variable completion-ignored-extensions so that when you are finding (which means opening in emacspeak) a file, autocompletion won't take into account files ending with specified extensions (the default value is rather sound, so you might not need tinker with it at all).

And finally, again if you use Emacs (and really, you should), you might want to learn about the dired-x extension to Dired mode, which includes a feature called omitting files (configurable using suffixes and/or regexps) which does the same as Nautilus' .hidden file, but better - it just works™ in all directories without creating any external files. (Edit: it seems that at least in Ubuntu, dired-x works out-of-the-box; when direding a directory, you may press M-o to toggle hiding all "uninteresting" files. You may also see the docs for how to enable this by default.)

Edit: I showed this little bash script to a friend today, and we noticed that the last two lines are more or less superfluous. It seems to me that a simpler script would do as well:

# make LaTeX intermediate files in the current directory hidden in Nautilus 
ls *.aux *.log *.toc &> /dev/null >> .hidden
  • The last two lines avoid repeating the same file over and over; otherwise, if you run this script after each TeX compilation, you could end up with hundreds of lines repeating the same filenames. If you want a one-liner, you could do ( cat .hidden; ls *.{aux,log,toc} 2> /dev/null ) | sort -u > .hidden Commented Feb 14, 2013 at 14:01
  • Actually, my suggestion seems to erase the previous contents of .hidden (which you may not care about anyway.) Note that &> redirects both standard output and standard error, so nothing is left! You probably mean 2> Commented Feb 14, 2013 at 14:09
  • This is great, it also works in the Dolphin file manager, if you use KDE Plasma!
    – Stardust
    Commented Aug 30, 2020 at 19:36

How to deal with all the *.aux, *.log, *.toc files and the like?

When pdfLaTeX compiles a *.tex file, you'll get once in a while an error message which makes you scratch your head and wonder what has gone wrong. And hiding your auxiliary files somewhere adds a source of errors to all other causes.

Most people prefer a clean desk. So what to do without making things more complicated?

Just delete the files once you are done.

My editor (Emacs) comes up with a cleaning function, which deletes all auxiliary files when I'm done with writing and got my PDF. Have a look at your editor, probably there is something similiar.

What I found very usefull on my Windows PC is a powershell script I call „Putzdienst“, I found it here: http://uweziegenhagen.de/?p=2095 and customized it to my needs. „Putzdienst“ can be translated as „cleaning service“.

And if you start writing your own script, be very carefull not to delete whole folders.

  • A neat and simple solution -- if you are willing to afford considerably longer compilation times every now and then.
    – krlmlr
    Commented Dec 21, 2012 at 10:20
  • Re the "clean desk" preference: if a mess on your desk means a mess in your head, what does an empty desk mean?
    – mbork
    Commented Dec 21, 2012 at 12:36

This doesn't quite answer the question, but I am using the following workflow for quite some time now. Instead of hiding the files I put them into a

Different output directory, with the help of latexmk and a Makefile

I use latexmk with the -output-directory switch and simply copy back the generated .pdf and .synctex.gz files (which are the only ones really needed to be in place). The process is automated with a Makefile, I have added a stripped-down version below:



all: texput.pdf

    latexmk -C

%.pdf: %.tex FORCE
    mkdir -p $(TMPDIR_BASE)$(subst .pdf,,$@)
    $(LATEXMK) -pdf -recorder -output-directory=$(TMPDIR_BASE)$(subst .pdf,,$@) -r .latexmkrc || true
    [ $@ -ef $(TMPDIR_BASE)$(subst .pdf,,$@)/$@ ] || cp -u -v $(TMPDIR_BASE)$(subst .pdf,,$@)/$@ .
    [ $*.synctex.gz -ef $(TMPDIR_BASE)$(subst .pdf,,$@)/$*.synctex.gz ] || cp -u -v $(TMPDIR_BASE)$(subst .pdf,,$@)/$*.synctex.gz .

You will need the file .latexmkrc which simply specifies the pdflatex call to use:

$pdflatex  =  'pdflatex -synctex=1 --src-specials';

(Of course, if you don't use SyncTeX, you can omit even that.)

For each source file, a separate subdirectory under the tmp/ directory is created, this can be changed by redefining TMPDIR_BASE. (.tmp/ works, too.)

To compile filename.tex, simply type make filename.pdf.

Note that, thanks to latexmk, compiling a .bib file works automagically, and it calls pdflatex just as many times as required. A recent version of latexmk is required for this Makefile, version 4.24 (from TeXlive 2012 on Ubuntu 12.10) didn't work for me. In fact, John Collins has implemented this feature in 4.27a. Specify the path to "your" latexmk in the LATEXMK variable. You can find everything at GitHub.


You could use a perl script to handle this:

use strict 'vars';
use File::Copy;
sub MAIN {
   ## call this by running the following from prompt:
   ## perl perl_code.pl <your_latex_filehandle>
   my ($filehandle) = @_;
   ## a list of suffixes generated by LaTeX, you may want to add others
   ## that you may need for your document.
   my @suffixes = qw / aux log toc ps /;
   ## testing whether filehandle exists and whether it ends in ".tex"
   if (( -e $filehandle ) && ($filehandle =~ /\.tex$/)){
      my $base_name = $filehandle;
      $base_name =~ s/\.tex$//;
      ## check to see whether there are hidden files that LaTeX needs to know about
      ## to properly compile file.
      foreach my $suffix ( @suffixes ){
     my $unhidden = $base_name . "." . $suffix;
     my $hidden = ".hidden_" . $unhidden;
     if ( -e $hidden){
        print "Unhiding:  " . $hidden . "\n";
        move($hidden, $unhidden) ;
      ## make a system call to "pdflatex" (I'm assuming this is the route you're using.
      system ("pdflatex $filehandle");
      ## hide files you want hidden.
      foreach my $suffix ( @suffixes ) {
     my $unhidden = $base_name . "." . $suffix;
     my $hidden = ".hidden_" . $unhidden;
     if ( -e $unhidden){
        print "hiding:  " . $unhidden . "\n";
        move($unhidden, $hidden) ;
    } else {
       print "\"$filehandle\" does not exist or is not a \".tex\" file.\n";
  • Note that this will cause problems for things like bibtex (unless all necessary compilation commands are executed in the same place where pdflatex is called), and will also affect log-parsing by IDEs etc. Commented Dec 21, 2012 at 9:10
  • There shouldn't be any problem since everything is getting unwrapped into the files that pdflatex expects to find (of course to that end some suffixes may need to be added to the suffix list).
    – A.Ellett
    Commented Dec 21, 2012 at 16:21
  • I think you missed cyberSingularity's point that sometimes you need to run commands other than pdflatex, like bibtex etc., which also need to find the same files. Commented Feb 16, 2013 at 11:49

If you are using Git for version control (you should use some VCS), you can easily clean all untracked files with git clean -X. Check in the source files and the resulting PDF file, and you're set.

  • Interesting, though I wouldn't recommend checking in the resulting pdf into any VCS.
    – mbork
    Commented Dec 27, 2012 at 21:20
  • @mbork: Why? Most modern VCSes handle binary files fine, and with package updates frequent on CTAN you can't guarantee identical typesetting of old documents anymore which means you'd want an old PDF as well, even if this breaks the usual "only sources" rule of version control. (And if you don't check in the PDF, git clean -x will remove it.)
    – You
    Commented Dec 27, 2012 at 21:50
  • that's true. OTOH, it was a bit irritating when I checked in my pdfs when I recompiled and somehow the pdf was not binary-identical (e.g., it included date/time of compilation). And, as you said, the rule of thumb is not to check in non-source files.
    – mbork
    Commented Dec 27, 2012 at 21:58
  • 1
    True. I guess a good compromise is to only check in the PDF at meaningful points. For instance, I check in the PDF when bumping the version number of my CTAN packages, but I usually don't check it in on all the commits between versions.
    – You
    Commented Dec 27, 2012 at 22:01
  • Good point. Again, though, I prefer just to hg ci -m "whatever" and not to worry about which files I check in.
    – mbork
    Commented Dec 27, 2012 at 22:03

The following answer is copied from my own answer for another relevant question.

You can remove the auxiliary files only after the "complete" PDF output is generated. The "complete" means that the cross-reference is properly typeset.

Removing the auxiliary files will be easier if you create a make file (in Linux) or a batch file (in Windows).

Last Edit:

An example of batch file (for Windows user) that not only compiles the input file several times (3 times should be enough) but also removes the auxiliary files at the end.

echo off

rem %1 TeX input filename without extension

rem %2 The number of times to invoke pdflatex in draftmode

if exist "%~1.pdf" del "%~1.pdf"

if exist "%~1.tex" for /l %%x in (1,1,%2) do pdflatex --shell-escape -draftmode -interaction=batchmode "%~1.tex"

if exist "%~1.tex" pdflatex --shell-escape "%~1.tex"

for %%x in (aux log out toc nav snm) do (if exist "%~1.%%x" del "%~1.%%x")

Note that %2 or the second mandatory argument specifies how many times we invoke pdflatex in draftmode. Thus there are %2 plus one pdflatex invocations in total.

If you really want to hide the auxiliary files (not recommended because you cannot overwrite the hidden files), the batch is as follows:

echo off

rem %1 TeX input filename without extension

rem %2 The number of times to invoke pdflatex in draftmode

if exist "%~1.pdf" del "%~1.pdf"

if exist "%~1.tex" for /l %%x in (1,1,%2) do pdflatex --shell-escape -draftmode -interaction=batchmode "%~1.tex"

if exist "%~1.tex" pdflatex --shell-escape "%~1.tex"

for %%x in (aux log out toc nav snm) do (if exist "%~1.%%x" attrib +h "%~1.%%x")

The LaTeX build wrapper ltx2any may be a solution. It does not hide 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 

Now to hide them from your view, there are a couple of ways:

  1. specify this folder as an hidden subfolder, e.g. .test/

  2. or specify some folder in tmp if you just need the files for compilation and check for errors etc immediately afterwards, but not in the long run.

You must log in to answer this question.

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