2

I've been trying to use shell escape and tikz externalize (see for instance here), but I have two issues:

  1. when the tikz picture fails with some errors, the compilation does not stops if it compiled on a previous version of the picture (instead the last picture that compile will be used forever). This is very annoying as I may think that a change was applied... while in fact it is not.
  2. the errors are highly non-helpful: if the picture fails to compile at the first compilation, I see only a generic error l.13 \end{tikzpicture}, otherwise as explained above it does not even stop the compilation and only prints system returned with code 256. Compare with the error obtained without externalization: ! Package pgf Error: No shape named C' is known.`

Is there any solution to:

  1. always stop compilation if a shell escape fails
  2. displays a meaningful error

MWE

Compile with pdflatex -shell-escape file.tex to see the problem 2. To see error 1, comment the last line, compile, uncomment the last line, and recompile.

\documentclass[]{article}

\usepackage{tikz}
\usetikzlibrary{external}
\tikzexternalize


\begin{document}


\begin{tikzpicture}
  \node (A) {A};
  \node (B) at (1,1) {B};
  %% If you want to see problem 1, you can compile once with this line first, then comment it back.
  % \node (C) at (1,0) {C};
  %% otherwise, this line should produce an error 
  \draw (A) -- (C);
\end{tikzpicture}


\end{document}

EDIT (problem 2 solved, problem 1 remains)

Thanks to David Carlisle, I realized that the issue 2 can be solved by either looking at the .log file given above in the error message (it's a bit long to do), or just go to the next error (with "Enter", or in emacs with shell-escape enabled, it can be done using C-c backtick). Ulrike Fischer also proposed to remove the batchmode in the /tikz/external/system call command. And indeed, if I use:

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

the error is now written directly to the console, thanks! So problem 2 is solved!

However, none of these answers solve the issue 1: even after removing the batchmode, they still produce a valid pdf: Output written on file.pdf (the error is now written in the log the first time it is compiled with an error, but may be hard to see without reading the whole log. Moreover, it disappears after the second compilation):

Here is a whole transcript:

$ cat file.tex 
\documentclass[]{article}

\usepackage{tikz}
\usetikzlibrary{external}
\tikzexternalize
\tikzset{external/system call={pdflatex \tikzexternalcheckshellescape -halt-on-error -jobname "\image" "\texsource"}}


\begin{document}


\begin{tikzpicture}
  \node (A) {A};
  \node (B) at (1,1) {D};
  %% If you want to see problem 1, you can compile once with this line first, then comment it back.
  \node (C) at (1,0) {C};
  %% otherwise, this line should produce an error 
  \draw (A) -- (C);
\end{tikzpicture}


\end{document}


$ pdflatex -shell-escape file.tex 
[...]
Output written on file-figure0.pdf (1 page, 9822 bytes).
[...]
Output written on file.pdf (1 page, 10695 bytes).
Transcript written on file.log.


$ cat file.tex ## see the commented line
\documentclass[]{article}


\usepackage{tikz}
\usetikzlibrary{external}
\tikzexternalize
\tikzset{external/system call={pdflatex \tikzexternalcheckshellescape -halt-on-error -jobname "\image" "\texsource"}}


\begin{document}


\begin{tikzpicture}
  \node (A) {A};
  \node (B) at (1,1) {D};
  %% If you want to see problem 1, you can compile once with this line first, then comment it back.
  %\node (C) at (1,0) {C};
  %% otherwise, this line should produce an error 
  \draw (A) -- (C);
\end{tikzpicture}


\end{document}


$ pdflatex -shell-escape file.tex
[...]
! Package pgf Error: No shape named `C' is known.
[...]
system returned with code 256
[...]
Output written on file.pdf (1 page, 10695 bytes).
Transcript written on file.log.


^__ See that even if the file contains an error, it does compile until the end. One needs to carefully inspect the log to see that an error occured. And even worse, if we compile a second time, it compiles fine without any error! See:


$ pdflatex -shell-escape file.tex 
[...]
===== Image 'file-figure0' is up-to-date. ======
[...]
Output written on file.pdf (1 page, 10695 bytes).
Transcript written on file.log.

as you can see, when an error occurs, it displays an error in the log but does not stop the compilation (this error can be hard to see in large documents, or if you compile from emacs directly that will just say "no errors occured"). Even worse, if you compile twice, then the error is completely gone from the log file, and the outdated picture is showed instead! This is really annoying as one may think that the typo is fixed while in fact it is not.

EDIT

After removing -halt-on-error as suggested in comments, it fails (as expected) the first time I compile. But if I recompile another time, it just says ===== Image 'file-figure0' is up-to-date. ====== while I would expect it to fail again. I guess that tikz updates the md5 irrespective of the success of the compilation... I'm not sure if there is a workaround or if it is a bug.

tobiasBora
  • 8,684
  • Erh, how is your problem related to the subject of your problem? I see no phantomsection or appendix. – daleif Feb 08 '22 at 10:09
  • Erh 2, have you tried the code without externalize? (C) is not defined. – daleif Feb 08 '22 at 10:12
  • @daleif Oups, thanks, I corrected the title (I was editing a question and forgot to update the title). Concerning Erh2, it's not an error, it's exactly the point: if I compile without externalize, I get a nice error about C being not defined. If I compile with externalize, the error is useless or not even blocking the compilation. My question is therefore "how to display a meaningful error and/or block the compilation in case of an error" – tobiasBora Feb 08 '22 at 10:18
  • I do not understand what you want us to see. You say you "just get a generic error l.13 \end{tikzpicture" but that is the last line of a multi-line error message. If I run the posted code without shell-escape I get this multi-line error message – David Carlisle Feb 08 '22 at 10:34
  • @DavidCarlisle Sure, but this multi-line message is not more explicit: by reading at it, can you guess that the reason of the failure is that (C) is not defined? So far, it just says "the compilation failed, not sure why, maybe you forgot -shell-escape?" Also, this error will not even appear if you compile once without any error and add the error on a second compilation. – tobiasBora Feb 08 '22 at 10:36
  • 1
    If I run without shell escape the error about C comes next on the same run, if I run with shell-escape that tells me there is an error in bb912-figure0 and if I look in bb912-figure0.log it says ! Package pgf Error: No shape named \C' is known.` which seems clear enough. – David Carlisle Feb 08 '22 at 10:39
  • Ok, I missed the fact that the log are written in bb912-figure0.log, thanks for pointing that. Maybe it's an indication that it would be clearer to write this log file directly on the output directly? ^^ And indeed, if I press "Enter" the error appears (thanks for pointing that, usually I quit right after the first error), in emacs I can type C-c backtick to go to the next errors and it seems to work. Thanks! But the issue 1 is still there, is there any method to solve this one? – tobiasBora Feb 08 '22 at 10:47
  • 1
    change the system call, remove the batchmode from it, see the documentation of /tikz/external/system call, – Ulrike Fischer Feb 08 '22 at 10:52
  • @UlrikeFischer Thanks for this: so this is a different (and more efficient I think) way to solve the issue as it displays directly the error in the log without needing to go to the next error (it should be the default ^^). However, it still does not solve my first issue. See my edit, I provided a full transcript. – tobiasBora Feb 08 '22 at 11:14
  • 1
    remove the -halt-on-error. – Ulrike Fischer Feb 08 '22 at 11:42
  • @UlrikeFischer Interesting, it works for the first compilation, but if I cancel the error and compile again, it displays no more error. I guess it updates the .md5 before checking if the compilation succeeds or not, so even if it fails it thinks that it worked... – tobiasBora Feb 08 '22 at 11:53
  • it fails for me also in the second compilation if I stop the first with x. But depending on what you do it could create a pdf and confuse the tests. – Ulrike Fischer Feb 08 '22 at 11:56
  • Really? I tried to stop with both x or Ctrl-D, both of them have the issue. Have you first compiled with a working figure (so that it generates a first pdf) before introducing errors? Btw, I filled a bug here https://github.com/pgf-tikz/pgf/issues/1137 – tobiasBora Feb 08 '22 at 12:07

1 Answers1

1

So I'll put here the discussion in comments (thanks David and Ulrike):

Basically, the error that is displayed says "look in the file FILE-figureX.log for the error. One solution is to read that file, or to press "Enter" to go to the next error: the next error is actually the compilation error. If you use emacs, make sure to add in your file:

% Local Variables:
% TeX-command-extra-options: "-shell-escape"
% End:

to enable shell-escape, reload it using M-x revert-buffer, and use the shortcut C-c backtick after the compilation to go to the next error.

A third solution (that I prefer because it also fails the first time the compilation fails), is to add:

\tikzset{external/system call={pdflatex \tikzexternalcheckshellescape -jobname "\image" "\texsource"}}

This will directly display the error on screen.

Unfortunately, none of these solution completely solve the issue 1. This is a tikz issue, that I reported here.

tobiasBora
  • 8,684