Hi! ConTeXt can detect issues in the sources and report them on the console with the argument --errors or with \enabledirectives [logs.errors]. The return value is still “0” (=success) even with errors present. Right now I use a script that parses the log file and lets me know if a run has issues. However, it would be great if context could return a non-zero value if errors are present. I've found that \enabledirectives [logs.errors=missing characters] returns “1” if characters are missing. Lovely! Undefined control sequences always return 1 (a TeX thing I believe and not related to the macro package). But undefined control sequences don't show up on the console as the other errors do if general output (except errors) is silenced e.g. with context --silent --noconsole --nostatistics --errors <file> The question is, what other directives can be enabled that make context return a failure? Is there a way to return failure if *any* error is encountered or do they need to be enabled each individually? And is there a way to show hard TeX errors as undefined control sequences as a “possible issue” if output is silenced? MWE: %% enables logging of errors same as --errors AFAIK \enabledirectives [logs.errors] %% makes context return 1 on missing chars, great! %% \enabledirectives %% [logs.errors=missing characters] \starttext %% missing characters 𝒜 %% missing figure \externalfigure [foo] %% \end occurred inside a group at level 1 %% ### semi simple group … entered at line \startalignment [middle] foo %% missing references See \in{section}[sec:none]. %% undefined control sequence %% \undefined \stoptext Marco
Hi Hans, a followup to our conversation in the meeting: here's an MWE demonstrating that errors aren't passed on to the runner script, except for "logs.errors=missing characters", which in fact do return failure, all others do return success. %% enables logging of errors same as --errors \enabledirectives [logs.errors] \starttext %% ### semi simple group … entered at line \startalignment [middle] foo \stoptext Marco
On 12/15/2021 4:21 PM, Marco Patzer wrote:
Hi Hans,
a followup to our conversation in the meeting: here's an MWE demonstrating that errors aren't passed on to the runner script, except for "logs.errors=missing characters", which in fact do return failure, all others do return success.
%% enables logging of errors same as --errors \enabledirectives [logs.errors]
\starttext
%% ### semi simple group … entered at line \startalignment [middle] foo
\stoptext You can check in the next upload:
- The 'failure' that you saw was actually a real lua error because I hadn't adapted some fancy, a very old 'around' 2006 feature, seldom used as it's more 'an example of possibilities' code to luametatex yet ... fwiw, we still share some lua files between engines. - Afaiks you should now get return code 1 for other cases (say you give \foo without meaning). It's a it tricky as this info has to pass through several subsystems. - The runaway error is actually kind of special (there are a few more) where the engine simply quits in confusion and doesn't exit hard as error (often because tex could somehow recover). If needed I can actually do a real error but it's not entirely compatible then (not that i care that much about compatibility in these shady areas.) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On Wed, 15 Dec 2021 20:48:29 +0100
Hans Hagen
You can check in the next upload:
- The 'failure' that you saw was actually a real lua error because I hadn't adapted some fancy, a very old 'around' 2006 feature, seldom used as it's more 'an example of possibilities' code to luametatex yet ... fwiw, we still share some lua files between engines.
Thanks for looking into that. I'll check the next upload.
- Afaiks you should now get return code 1 for other cases (say you give \foo without meaning). It's a it tricky as this info has to pass through several subsystems.
Hard TeX errors (like \undefined) already return 1.
- The runaway error is actually kind of special (there are a few more) where the engine simply quits in confusion and doesn't exit hard as error (often because tex could somehow recover). If needed I can actually do a real error but it's not entirely compatible then (not that i care that much about compatibility in these shady areas.)
I'd vote to handle those as hard errors because 1) Luametatex isn't focused on compatibility. 2) The user explicitly requested error reporting (by providing --errors). 3) No one is recovering tex runs these days. Marco
On 12/15/2021 9:16 PM, Marco Patzer via ntg-context wrote:
On Wed, 15 Dec 2021 20:48:29 +0100 Hans Hagen
wrote: You can check in the next upload:
- The 'failure' that you saw was actually a real lua error because I hadn't adapted some fancy, a very old 'around' 2006 feature, seldom used as it's more 'an example of possibilities' code to luametatex yet ... fwiw, we still share some lua files between engines.
Thanks for looking into that. I'll check the next upload.
- Afaiks you should now get return code 1 for other cases (say you give \foo without meaning). It's a it tricky as this info has to pass through several subsystems.
Hard TeX errors (like \undefined) already return 1.
- The runaway error is actually kind of special (there are a few more) where the engine simply quits in confusion and doesn't exit hard as error (often because tex could somehow recover). If needed I can actually do a real error but it's not entirely compatible then (not that i care that much about compatibility in these shady areas.)
I'd vote to handle those as hard errors because
1) Luametatex isn't focused on compatibility.
ok, but let's first test this ... it's mostly cosmetics (read: come up wiht a better error message than the default sometimes unclear tex one)
2) The user explicitly requested error reporting (by providing --errors).
3) No one is recovering tex runs these days. indeed, makes no sense (it all dates from (paper) terminals and night-time runs .. the good old 300 baud transfer days)
Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On Thu, 18 Nov 2021 19:27:25 +0100
Marco Patzer via ntg-context
Is there a way to return failure if *any* error is encountered or do they need to be enabled each individually?
A solution is to use patterns (supported in the upcoming upload): \enabledirectives [logs.errors=*] Alternatively use a compile-time switch: context --errors='*' <file> This will make the return value reflect the presence of an error. Further reading: https://wiki.contextgarden.net/Running_ConTeXt#--errors Marco
participants (2)
-
Hans Hagen
-
Marco Patzer