[tex-live] etex

[jfbu]

Hi David,

Le 10 janv. 2017 à 14:23, David Carlisle <d.p.carlisle at gmail.com> a écrit :

> ...

thanks,

I was not precise enough about mismatched, my use case was
indeed with missing \fi not missing \if

> 
> conversely
> 
> \if aa
> \end
> 
> 
> is not an error you just get a warning
> 
> (\end occurred when \if on line 3 was incomplete)
> 
> 
> and an exit status of 0.
> 
> So the distinction is not really that tex gives different exit status
> for different errors, but that some things that one might expect to be
> an error are just a warning.

ok


> 
> I think the distinction matters as the exit code is a system dependent
> thing and could be potentially changed, but changing whether primitive
> TeX syntax generates an error or a warning would be changing the
> documented behaviour of tex which is more problematic (perhaps)
> 

what about exit code 2 for warnings ?

it would still be a change in behaviour ... but would not mix errors
and warnings in the same bag

I understand tex should not change, but what about etex ?

I guess integrated editors do not care because they parse the log file
for more precise information anyhow.

But this situation is frustrating for doing speedy shell scripts for
batch processing.

And I then would have to check all possible warnings and see if
I want my regression test suite to check the logs for all those
possibilities too... currently I grep for the string "occurred" which
is enough to
pick the missing \fi's and the missing \endgroup's ...

(my logs are small hence I didn't even wonder if using "tail"
before "grep" could speed up things, if someone more experienced than
me in shell scripting has an advice, I would be grateful)

Does there exist TeXLive supported systems which have only 0 or 1 for exit
codes of processes ? (or no exit codes at all ?)

and
Off-Topic: does someone know if e-TeX ever considered introducing
a \showboxtofile{foo}<box number> primitive which would do like \showbox
but with
target something else than the log file, and more importantly would not
raise an "error" ?


Jean-François