[Toybox] Testing: how to check return code (Rob Landley)

[Rob Landley]

On 11/4/19 4:46 AM, scsijon wrote:
> 
>> Message: 2
>> Date: Sun, 3 Nov 2019 19:01:14 -0600
>> From: Rob Landley <rob at landley.net>
>> To: toybox at lists.landley.net
>> Subject: Re: [Toybox] Testing: how to check return code
>> Message-ID: <c3a291b2-bd33-0854-f5ef-9f97e1fe7a79 at landley.net>
>> Content-Type: text/plain; charset=utf-8
>>
>> On 10/30/19 1:56 PM, enh via Toybox wrote:
>>>> I am with you enh. In this case, I wanted the error code because
>>>> GNU `ls` says the command can exit with { 0, 1, 2 }.
>>>> https://linux.die.net/man/1/ls
>>>> POSIX says exit status is { 0, >0 }
>>>> https://pubs.opengroup.org/onlinepubs/9699919799/
>>>> In this case which specification wins?
>>>
>>> they're both true, but the GNU ls is more specific :-)
>>
>> Hmmm, I need to add http://man7.org/linux/man-pages/dir_section_1.html to the
>> roadmap, don't I? Except a quick cut and paste pipe through wc says there's just
>> under 1500 entries in there...
>>
>>>> enh, the other week you mentioned Android will not use the build if
>>>> there are failing tests.
>>>
>>> correct. that's why i'm a bit behind --- xargs is still failing.
>>
>> I thought I checked in your 4k workaround last week? (Commit f95d580892e2 ?)
>>
>> Hmmm, just did a "git push" and it found stuff... (Sorry, Japan's been as busy
>> as you'd expect.)
>>
>>>> Does the above apply to `TEST_HOST=1
>>>> make tests`? If so, then I will rewrite the test.
>>>
>>> not at the moment, no, but you probably want `SKIP_HOST=1` before the
>>> affected `testing` (but on the same line so it doesn't apply to later
>>> instances)?
>>
>> I'm trying to migrate from SKIP_HOST to toyonly, because you could in theory
>> have toybox on the host and the decision we're really making is "this is known
>> to work in toybox, but not anywhere else".
>>
>> Note: toyonly is a shell function that does an eval on its arguments instead of
>> an environment variable that signals the plumbing to make a decision, so it's
>> called slightly differently. But there should be a few examples in the tree...
>>
>>> or fix ls to behave like the host. see grep for a similar example.
>>> (or, generally, grep for `exitval`.)
>>
>> I still wince at being too specific in the tests, but if there are actual
>> examples of scripts caring about this level of detail and being broken by not
>> getting it right... then the help text output should probably mention the error
>> codes.
>>
>> And _possibly_ we should work out some standard behavior to enforce across the
>> commands? If "0" and "1" determine the result of a test (like cmp), neither of
>> which is actually an error, then "2" being the default _error_ value everywhere
>> might make sense? (But would we then break scripts expecting 1?)
>>
>> I'm uncomfortable whack-a-moling this. I kinda want a rule.
>>
>> Rob
>>
> UM, I sort of wonder what we do with these?
> 
> From http://www.tldp.org/LDP/abs/html/exitcodes.html, Table E-1. Reserved Exit
> Codes.

Yet another documentation source that isn't trying to be a standard? (I was more
familiar with the linux documentation project 15 years ago, I'm not sure of its
current status?)

I can't pull that up right now because wifi's being weird in akasaka (taking the
train from asakusa to akasaka was hard for me to keep straight), but I doubt it
helps us be authoritative or systematic about this?

> Especially the line below the table where they talk of exit codes 1 - 2, 126 -
> 165, and 255, all having special meanings, and should therefore be avoided for
> user-specified exit parameters.

127 is the shell's way of saying it couldn't find your binary. 128+SIGNAL is the
exit code you get from the SIG_DFL handler when a process is killed by signals.
0 and 1 are kinda the default "it worked" and "it didn't work" values. And it
looks like some processes are define to return 2 (generally things that find or
compare, to distinguish "find/compare negative result" from "error occurred").

I know _why_ all those values occur and when to use them. (Modulo errno-base
only goes up to 34 which is 162, so 165...?

My guess was that 126 would be the dynamic loader saying it couldn't find one of
the required .so files, except musl/ldso/dynlink.c is returning 127 for that.
And 255: not a clue...

Rob