On 06/11/19 19:13, Rob Landley wrote:
On 11/4/19 4:46 AM, scsijon wrote:
Message: 2
Date: Sun, 3 Nov 2019 19:01:14 -0600
From: Rob Landley <r...@landley.net>
To: toybox@lists.landley.net
Subject: Re: [Toybox] Testing: how to check return code
Message-ID: <c3a291b2-bd33-0854-f5ef-9f97e1fe7...@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?)
now on a wiki at http://wiki.tldp.org/ and apparently kept up to date.
The LDP website consists of two parts: the first part is a collection of
documents, mostly the famous "HOWTO"s, but also some Guides. This
collection is available in many flavours, from html for online reading
to docbook source for rendering in many other document formats. This
part of the site is mirrored all over the world.
Although this seems to be the latest covering this subject on the site
and it marked as "Current/Maintained", so ......
Advanced Bash-Scripting Guide
An in-depth exploration of the art of shell scripting
Mendel Cooper
<thegrendel....@gmail.com>
10 Mar 2014
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...
from the (matching) table in the wikka>
Exit Code Number Meaning Example Comments
1 Catchall for general errors let "var1 = 1/0" Miscellaneous errors,
such as "divide by zero" and other impermissible operations
2 Misuse of shell builtins (according to Bash documentation)
empty_function() {} Missing keyword or command, or permission problem
(and diff return code on a failed binary file comparison).
126 Command invoked cannot execute /dev/null Permission problem or
command is not an executable
127 "command not found" illegal_command Possible problem with $PATH or a
typo
128 Invalid argument to exit exit 3.14159 exit takes only integer args
in the range 0 - 255 (see first footnote)
128+n Fatal error signal "n" kill -9 $PPID of script $? returns 137 (128
+ 9)
130 Script terminated by Control-C Ctl-C Control-C is fatal error signal
2, (130 = 128 + 2, see above)
255* Exit status out of range exit -1 exit takes only integer args in
the range 0 - 255
(sorry for the format, but that's the way it copied)
Rob
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
