Commit c81bb9d
committed
When latex fails, make sure it does not write a dvi.
PR 10180 added some tests checking that when the latex subprocess used
by usetex fails, a RuntimeError does propagate up to the Python process.
It originally passed the CI, but since its merge, various CIs have been
failing on the test that a text with `$22_2_2$` (an invalid tex
construct) fails when usetex is set.
This is because while `latex --interaction=nonstopmode` does exit with
error code 1 when processing a file with that construct, the error is
"benign" enough that it still writes a dvi before exiting (the contents
are simply as if the input was `$22_{22}$`). The dvi goes into the tex
cache and later CI runs pick up the cached dvi instead of running the
subprocess, thus failing the test.
The solution is to use --halt-on-error on top of nonstopmode, see e.g.
https://tex.stackexchange.com/questions/258814/what-is-the-difference-between-interaction-nonstopmode-and-halt-on-error (and to clear your tex cache).
Note that before the PR, there would similarly be the weird behavior
(for the user) that the first attempt to use a "benignly" invalid tex
construct would trigger an exception, but latter attempts would not (for
the same reason as above).1 parent 44a9036 commit c81bb9d
1 file changed
Lines changed: 4 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
361 | 361 | | |
362 | 362 | | |
363 | 363 | | |
364 | | - | |
| 364 | + | |
| 365 | + | |
365 | 366 | | |
366 | 367 | | |
367 | 368 | | |
| |||
387 | 388 | | |
388 | 389 | | |
389 | 390 | | |
390 | | - | |
| 391 | + | |
| 392 | + | |
391 | 393 | | |
392 | 394 | | |
393 | 395 | | |
| |||
0 commit comments