I'm a command-line junkie and often compile with a simple pdflatex filename.tex from a terminal, and I forget (or am too lazy) to type -interaction=nonstopmode or interaction=batchmode. Hence, when I encounter errors, I've given the interactive prompt, which I find confusing and unintuitive, and usually get out of it as quick as possible with 'q'.

Does anyone make use of the interactive prompts, and find them useful or advantageous as opposed to simply parsing the .log file, fixing the problem and recompiling from the beginning? Is it worth learning the interactive system?

If I had to guess, I'd suppose the interactive mode hasn't changed much since the early days of TeX, when it took much longer to compile a document, and you might not want to start from scratch when you made one tiny mistake. But now that compilation takes seconds at most, is there a compelling reason ever to use interactive mode?

I ask partly because I'm on the verge of putting alias pdflatex='pdflatex -interaction=batchmode' in my .bashrc, but I wonder whether anyone thinks I'd be losing anything by doing so. If so, is there any free documentation out there about how to use the interactive system? (Or am I overthinking/overcomplicating it?)

  • 6
    The thing I like about it is precisely that it stops on the first error and gives me the error message and line. So I don't have to hunt for the error in the complete log. For longer documents the fact that you can immediately stop (with x, not q) is useful, because it potentially saves the time it takes the rest of the document to compile (or fail). It is also useful for debugging with \show. – Caramdir Aug 9 '11 at 4:38
  • 2
    @Caramdir why not make that an answer? – frabjous Aug 9 '11 at 13:46
  • It was kind of late and I didn't want to write a full answer. Anyway, Ulrike's answer has the same points. – Caramdir Aug 9 '11 at 16:05

I, too, think that the interactive mode was important when the edit-compile-test cycle was very long and one couldn't afford to start over for each mistake.

However, today we are more accustomed to the Unix style of error reporting, where an utility would print the error and exit immediately. Luckily, there is a command line switch combination that does precisely that:

pdflatex -interaction=nonstopmode -halt-on-error

With this command line, only the first error is printed on the terminal, and control is returned to the shell. The only disadvantage is that you can't type H anymore to read the error help — but if you have at least some experience with LaTeX, you will not need the error help text very often.


I sometimes use the interaction mode for debugging. You can insert code by using I in the prompt. Then I often write \makeatletter\show\@some@internal@macro or something similar. The \show will get you another prompt and can again use I to add more code. I find this faster than placing this debug code in the document if it is just done once anyway. Otherwise you have to abort, edit your code, compile and change your code back again.

Any real fixes of the code I do in the original file, not in the interactive mode, otherwise it would get lost.

Note that you could define aliases (Unix/Linux) or Shell/Batch scripts to call pdflatex in nonstopmode or batchmode. I also use Makefiles as mentioned by Raphink. Also latexmk is very useful (needs the -pdf option for PDF output). Finally there are the \nonstopmode and \batchmode macros (actually primitives) which can be used in the document to change to that mode.

  • 2
    You can get an interactive command prompt easier. Run latex without any arguments and type \relax. Then you can enter any commands you wish. End of file (Ctrl+D on Unix) ends the session. – Andrey Vihrov Aug 9 '11 at 11:46
  • 1
    @Andrey: Thanks, I know that. I was talking about debugging an issue in a document which caused an error. I used what you describe quite often to display definitions but then wrote texdef for that. – Martin Scharrer Aug 9 '11 at 11:52
  • @Andrey: that's what I do. But I just found out that % is faster to type than \relax. – Bruno Le Floch Aug 9 '11 at 14:32
  • I find this useful when I try to compile Latex documents with missing and unknown style files, which allows me to see the use of macros at the point I discover that they are not bound. A decent debugger for Tex would be a wonderful thing for the few of us who do this sort of thing a lot. – Charles Stewart Aug 26 '11 at 19:54

Instead of setting an alias like you're doing, I usually write a Makefile for projects, with something like:


%.pdf: %.tex
        TEXINPUTS=$(TEXINPUTS) xelatex -shell-escape -interaction=batchmode $*
        TEXINPUTS=$(TEXINPUTS) xelatex -shell-escape -interaction=batchmode $*

so I just type make mydocument.pdf to build my PDFs. Whenever I have errors, I like to relaunch the command without the -interaction=batchmode bit so that it stops interactively and I can see exactly where the code fails. I do not use the interactive console per se though, I only press X most of the time.


I'm not a command line junkie (I'm starting almost every compilation through shortcuts or buttons in winedt) but I'm always running latex in interactive mode. Also I'm not using the integrated console of my editor instead I have setup winedt so that it pops up the normal command window and pause at the end of the run. This means at every error/halt I have to decide how to react (depending on the error with enter, x or sometimes s), can use \show in my document and can check fonts, file size and the other informations you get at the end without having to open the log.

I'm not doing it to save time but because I get more control, more informations and can't forget to correct an error. (Imho at least newbies should avoid \scrollmode. It leads them to ignore errors as long as they are not fatal.)


if there were only one error in the file being processed, a batch approach could be appropriate. but if there is more than one error, using the interactive approach permits one to correct the error interactively and continue on, find other errors, and potentially correct them as well so the job completes. (one typical error is the misspelling of a command name; often a simple in-line \let or definition will take care of multiple instances of the same error.) then go back, fix what's reported in the log (making sure to check for multiple instances of whatever misspelling caused you to enter an interactive workaround), and you're on your way.

in the case of a really fatal error, where one error triggers many others and can't be corrected simply in-line, it's time to quit, go back to the log, fix the known problems, and restart. in documents with heavy math, this process is much simpler and quicker than slogging through an "incomplete" log -- tex dropped out after too many errors reported -- and iterating in batch mode. in fact, the current speed of compilation makes this approach even more attractive than it used to be in the bad old days of tortoise-speed machines.

once the file is clean, batch mode is appropriate for multiple runs to generate good citation links and final index and table of contents.

i'm a command-line junkie too, so that's not a relevant consideration here.


I forget (or am too lazy) to type -interaction=nonstopmode or interaction=batchmode.

Or in my case, I didn't bother to read the manual to find that such an option exists. There is an alternative that works quite nicely for makefiles: Force latex (or in my case pdflatex) to receive input from /dev/null rather than the terminal. This of course gives an immediate EOF, which in turn results in an ! Emergency stop in latex.

$(PDF_FILES): %.pdf : %.tex
  cat /dev/null | $(PDFLATEX) $(basename $(@F)).tex
  cat /dev/null | $(PDFLATEX) $(basename $(@F)).tex
  • 8
    Or you use cmd < /dev/null; see Useless use of cat. – Andrey Vihrov Aug 9 '11 at 17:07
  • quite hackish, but good to know nonetheless ;-) – ℝaphink Aug 9 '11 at 21:36
  • Thanks for that tip! I used yes X | make in automated tests because I wanted to test the same command as we would use when building normally (namely "make" with the default target), but when it prompts for a filename and you pass X, it will happily continue and exit with status 0, causing the test to succeed while the pdf is actually messed up. Passing /dev/null on stdin instead (</dev/null make) makes it fail when it fails! I like it. – Luc Apr 3 '20 at 9:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.