I'm using Tikz' externalize function to speed up compilation of documents with a lot of plots. This works fine on any System except my Mac with MacTex 2014. pdflatex fails when tikz calls it's own "pdflatex \tikzexternalcheckshellescape -halt-on-error -interaction=batchmode ... " because tikz complains it can't find pdflatex. pdflatex, however is definitely in my PATH environment. If I modify tikz externalize call to use an absolute path like this it works just fine:

\tikzset{external/system call={%
        /usr/texbin/pdflatex \tikzexternalcheckshellescape
        -halt-on-error -interaction=batchmode
        -jobname "\image" "\texsource"}}

BUT, using a relative path to pdflatex, like this, does not work:

\tikzset{external/system call={%
        pdflatex \tikzexternalcheckshellescape
        -halt-on-error -interaction=batchmode
        -jobname "\image" "\texsource"}}

However since I use the same code on different machines ans OSes it don't want to explicitly define the absolute path of pdflatex. Any idea why the "inner" call of tikz won't find pdflatex? PS: Texstudio calls pdflatex with a relative path just fine. pdflatex is added to the PATH by /etc/paths.d/TeX, the default way for MacTeX 2014.

@JLDiaz: If I compile the main document with "interaction=nonstopmode" tikz just complains, that it could not find a pdf file (because the creation failed).

! Package tikz Error: Sorry, the system call 'pdflatex -shell-escape -halt-on-e
rror -interaction=batchmode -jobname "testplot.tikz" "maindoc"' did NOT
 result in a usable output file 'testplot.tikz' (expected one of .pdf:.jp
g:.jpeg:.png:). Please verify that you have enabled system calls. For pdflatex,
 this is 'pdflatex -shell-escape'. Sometimes it is also named 'write 18' or som
ething like that. Or maybe the command simply failed? Error messages can be fou
nd in 'testplot.tikz.log'. If you continue now, I'll try to typeset the p

If I allow pdflatex to halt on error it stops with the error

sh: pdflatex: command not found

where "pdflatex" in the latter case is the one called by tikz.

PS: testplot.tikz.log is not created, since pdflatex is not found

  • @JLDiaz: I didn't know how to paste code in a comment, so I edited the original question. Feb 4, 2015 at 17:22
  • Ok, I tried to trick tikz by setting \tikzset{external/system call={echo $PATH > test.log}} which writes the PATH tikz should see into test.log. The content of test.log is then: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/texlive/2012/bin/x86_64-darwin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/texbin I wonder what ...textlive/2012 does in that path, its a freshly installed computer and i can't remember putting anything with texlive 2012 on that machine (besides that folder does not even exist). /usr/local/texlive/2014/, however exists Feb 4, 2015 at 18:19
  • I wrote an answer summarizing our findings in the chat. I think we cand delete all these comments now (I deleted mine)
    – JLDiaz
    Feb 4, 2015 at 19:17

1 Answer 1


I'm posting here the final "solution" (you'll understand the quotation marks later), found through a chat conversation, as reference for other users which (unlikely) could face the same issue, and to document some strategies for debugging this kind of problems.

The main suspect here was the value of the PATH variable "visible" by the shell which pdflatex launches to execute \write18 commands. This shell is sh, which in most modern systems (and in particular in OSX) is the same than bash. The value of the PATH in this sub-shell is expected to be the samen than the system path "visible" from the terminal.

By putting this snippet in the preamble of the tex document,

\tikzset{external/system call={echo $PATH > test.log}}

when tikz tries to externalize an image, instead of launching pdflatex (which failed), it will write the actual value of the PATH variable as seen by this sub-shell in the test.log file. The result was:


There are some surprises in this PATH:

  • It is different from the PATH which can be seen in a terminal via echo $PATH
  • It contains one wrong directory (/usr/local/texlive/2012/bin/x86_64-darwin) which should not be here. The folder does not exist, and indeed, according to the OP, this machine never had Texlive 2012 installed. Where this part of the PATH came from, is a mistery.
  • It contains the right directory /usr/texbin at the end. This is the directory where pdflatex is, so the externalization command should have worked anyway.

Totally puzzled by these shocking facts, and in dispair, I suggested the following snippet at the preamble:

\tikzset{external/system call={%
         PATH=/usr/texbin:$PATH pdflatex \tikzexternalcheckshellescape
        -halt-on-error -interaction=batchmode 
        -jobname "\image" "\texsource"}}

Against my expectations, it worked!

This "solution", simply adds the folder /usr/texbin/ to the PATH, but this folder was anyway already in the path. The only difference is that now is the first folder to be tried. Somehow this made a difference (I still don't understand why).

So the problem was solved, but in a very unsatisfying way...

  • 4
    So, after a loooong search I finally found (part of) the problem: It turns out, that TeXstudio modifies the PATH that tikz sees. It is also responsible for the strange texlive/2012 path. I found this option in TeXstudio's preferences (advanced options)->build->commands ($PATH). I deleted the 2012 part and added /usr/texbin. Now everything works as supposed without any modification of the tex-file. Feb 4, 2015 at 22:55
  • @DayAndNight This also worked for me. Of course, I had to set the correct path (I just copied the one used in the regular pdflatex commands, which in my case is '/Library/TeX/texbin')
    – Yoda
    May 16, 2016 at 11:38
  • @JLDiaz On Windows, what is the equivalent to this PATH=/usr/texbin:$PATH pdflatex?
    – Diaa
    Feb 3, 2017 at 22:01

You must log in to answer this question.

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