Am 15.01.2018 um 03:37 schrieb Randall S. Becker:
On January 14, 2018 4:33 PM, I wrote:
The exotic error code coming back from perl is 162. I can muck with it, if
there was a value more useful to git.
* 553 } else if (WIFEXITED(status)) {
* 554 code = WEXITSTATUS(status);
(eInspect 3,887):p code
$4 = 162
The perl code uses die to terminate with a non-specific non-zero error code.
What it seems is that there is an assumed value that the git tests depend on,
but perl.org describes the following:
"die raises an exception. Inside an eval the error message is stuffed into $@
and the eval is terminated with the undefined value. If the exception is
outside of all enclosing evals, then the uncaught exception prints LIST to
STDERR and exits with a non-zero value. If you need to exit the process with
a specific exit code, see exit."
I take "die exits with non-zero" as a piece of information for the
*users* so that they can write "if perl foo.pl; then something; fi" in
shell scripts. I do *not* interpret it as leeway for implementers of
perl to choose any random value as exit code. Choosing 162 just to be
funky would be short-sighted. [I'm saying all this without knowing how
perl specifies 'die' beyond the paragraph you cited. Perhaps there's
more about 'die' that justifies exit code 162.] I'd say that the perl
port is broken.
So it seems that we might need to either not use die or change the tests not
to care about the exit code for specific tests involving perl. Suggestions?
Sadly, while changing the funky 162 completion code to 255 works
fine for t9001, it causes a bunch of other tests to fail (parts of
1308 and most of 1404). I can't tall whether this is test suite or
code related but I'm caught in the middle. Going to the platform
developers may eventually get the fix for t9001 (fixing perl), but
otherwise, I'm not sure why changing 162 to 255 causes 1308 and 1404
to blow so badly. In any event, I'm putting this away for a few days
due to $DAYJOB.
Why do you not choose 1? He, on my Linux box perl -e die exits with 255.
So...
-- Hannes
