Discussion:
Command exit numbers.
(too old to reply)
Rob Landley
2017-06-10 18:29:23 UTC
Permalink
Raw Message
Would it be useful if perror_exit() set exitval to errno by default
instead of 1? They're well defined values that let you know _what_ happened.

I just fixed grep so it doesn't error_exit() when it hits a dangling
symlink (because fdopen() failed to covert fd to file *), but
perror_msg() sets errno to 1, and "grep -rq blah" has 1 mean "didn't
find what we were grepping for". In this instance, finding it stops and
returns 0 immediately so if you hit one of those it won't change the
results, but the caller can't distinguish "did not find" from "hit
dangling symlink and wanted to report it as an error" unless they
capture stderr. In this case that's probably fine, but it made me think
about the more general problem.

The downside would be other commands that use error return values other
than 0 and 1 already. This could create false positives for that.

*shrug* Thought I'd ask. I still have this annoying cold and trying to
think through it myself right now isn't getting a lot of traction.

Rob
enh
2017-06-12 15:49:28 UTC
Permalink
Raw Message
Post by Rob Landley
Would it be useful if perror_exit() set exitval to errno by default
instead of 1? They're well defined values that let you know _what_ happened.
...except the caller doesn't know whether it's looking at an errno
value. and what could a caller realistically do anyway? it's bad
enough working out what exactly EINVAL means if the last thing you did
was call mmap, but if you just ran toybox... that failure could be
coming from anywhere.
Post by Rob Landley
I just fixed grep so it doesn't error_exit() when it hits a dangling
symlink (because fdopen() failed to covert fd to file *), but
perror_msg() sets errno to 1, and "grep -rq blah" has 1 mean "didn't
find what we were grepping for". In this instance, finding it stops and
returns 0 immediately so if you hit one of those it won't change the
results, but the caller can't distinguish "did not find" from "hit
dangling symlink and wanted to report it as an error" unless they
capture stderr. In this case that's probably fine, but it made me think
about the more general problem.
isn't grep a well-known special case?

"if any error occurs and -q is not given, the exit status is 2."
Post by Rob Landley
The downside would be other commands that use error return values other
than 0 and 1 already. This could create false positives for that.
i've certainly seen scripts explicitly check for 0 and 1 exit statuses.
Post by Rob Landley
*shrug* Thought I'd ask. I still have this annoying cold and trying to
think through it myself right now isn't getting a lot of traction.
seems to me like it would break a lot of expectations, while not being
obviously usable?
Post by Rob Landley
Rob
_______________________________________________
Toybox mailing list
http://lists.landley.net/listinfo.cgi/toybox-landley.net
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
Rob Landley
2017-06-13 22:52:32 UTC
Permalink
Raw Message
Post by enh
Post by Rob Landley
Would it be useful if perror_exit() set exitval to errno by default
instead of 1? They're well defined values that let you know _what_ happened.
...except the caller doesn't know whether it's looking at an errno
value. and what could a caller realistically do anyway? it's bad
enough working out what exactly EINVAL means if the last thing you did
was call mmap, but if you just ran toybox... that failure could be
coming from anywhere.
It's nonzero, and 99% of the time _all_ we're saying with the exit code
is "it's nonzero".

Right now it's providing the errno info in human readable format via
perror_exit(), and if a script really wants to know it can... parse the
string and hope nobody ever changes the locale? I guess that's the best
we can do. :P
Post by enh
Post by Rob Landley
I just fixed grep so it doesn't error_exit() when it hits a dangling
symlink (because fdopen() failed to covert fd to file *), but
perror_msg() sets errno to 1, and "grep -rq blah" has 1 mean "didn't
find what we were grepping for". In this instance, finding it stops and
returns 0 immediately so if you hit one of those it won't change the
results, but the caller can't distinguish "did not find" from "hit
dangling symlink and wanted to report it as an error" unless they
capture stderr. In this case that's probably fine, but it made me think
about the more general problem.
isn't grep a well-known special case?
Not according to posix?

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html
Post by enh
"if any error occurs and -q is not given, the exit status is 2."
https://xkcd.com/221/

Posix just says >1 for error, which A) I don't think I've implemented
yet, B) would argue against the errno approach because 1 is EPERM and
that's a commonish failure:

$ ./ls /root
ls: /root: Permission denied

That said, I can make grep _start_ returning 2 for errors. I still have
to do --color before you can use the toybox one. (Did 90% of it once and
got distracted for a month then lost it to a "git clean -fdx && git
checkout -f" in the wrong directory. As usual.)
Post by enh
Post by Rob Landley
The downside would be other commands that use error return values other
than 0 and 1 already. This could create false positives for that.
i've certainly seen scripts explicitly check for 0 and 1 exit statuses.
I was thinking "cmp", which is _currently_ doing the 0 1 or 2 thing. :)

Hmmm... that sort of implies perror_exit() should set errno to 2 instead
of setting it to 1? But again, a potentially intrustive change so
probably not.
Post by enh
Post by Rob Landley
*shrug* Thought I'd ask. I still have this annoying cold and trying to
think through it myself right now isn't getting a lot of traction.
seems to me like it would break a lot of expectations, while not being
obviously usable?
Yeah, I couldn't quite see the way to make proper use of this
information either. I thought that might be because I'm under the
weather, but if nobody else is seeing one...

It's probably one of those things where if toybox had done it from the
start, it'd be fine, but as the installed base grows the cost of changes
to existing commands gets higher. :P

Rob

P.S. I an wrestling with your help text processing issue as we speak,
hope to have the fix checked in today. And THEN I can cut the release...
enh
2017-06-14 00:11:25 UTC
Permalink
Raw Message
Post by Rob Landley
Post by enh
Post by Rob Landley
Would it be useful if perror_exit() set exitval to errno by default
instead of 1? They're well defined values that let you know _what_ happened.
...except the caller doesn't know whether it's looking at an errno
value. and what could a caller realistically do anyway? it's bad
enough working out what exactly EINVAL means if the last thing you did
was call mmap, but if you just ran toybox... that failure could be
coming from anywhere.
It's nonzero, and 99% of the time _all_ we're saying with the exit code
is "it's nonzero".
(i think we're in violent agreement at this point, but two other
things that occurred to me...)

except when it's 0 because we've called perror_exit on something that
didn't actually set errno. i'm sure i haven't seen "something went
wrong: Success" for the last time!

and some errno values are too large for an exit status: mips in
particular has plenty of errno values that would look like signals
(useful ones like ETIMEDOUT, even), and EDQUOT manages to be as high
as 1133.
Post by Rob Landley
Right now it's providing the errno info in human readable format via
perror_exit(), and if a script really wants to know it can... parse the
string and hope nobody ever changes the locale? I guess that's the best
we can do. :P
Post by enh
Post by Rob Landley
I just fixed grep so it doesn't error_exit() when it hits a dangling
symlink (because fdopen() failed to covert fd to file *), but
perror_msg() sets errno to 1, and "grep -rq blah" has 1 mean "didn't
find what we were grepping for". In this instance, finding it stops and
returns 0 immediately so if you hit one of those it won't change the
results, but the caller can't distinguish "did not find" from "hit
dangling symlink and wanted to report it as an error" unless they
capture stderr. In this case that's probably fine, but it made me think
about the more general problem.
isn't grep a well-known special case?
Not according to posix?
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html
Post by enh
"if any error occurs and -q is not given, the exit status is 2."
https://xkcd.com/221/
Posix just says >1 for error, which A) I don't think I've implemented
yet, B) would argue against the errno approach because 1 is EPERM and
$ ./ls /root
ls: /root: Permission denied
That said, I can make grep _start_ returning 2 for errors. I still have
to do --color before you can use the toybox one. (Did 90% of it once and
got distracted for a month then lost it to a "git clean -fdx && git
checkout -f" in the wrong directory. As usual.)
Post by enh
Post by Rob Landley
The downside would be other commands that use error return values other
than 0 and 1 already. This could create false positives for that.
i've certainly seen scripts explicitly check for 0 and 1 exit statuses.
I was thinking "cmp", which is _currently_ doing the 0 1 or 2 thing. :)
Hmmm... that sort of implies perror_exit() should set errno to 2 instead
of setting it to 1? But again, a potentially intrustive change so
probably not.
Post by enh
Post by Rob Landley
*shrug* Thought I'd ask. I still have this annoying cold and trying to
think through it myself right now isn't getting a lot of traction.
seems to me like it would break a lot of expectations, while not being
obviously usable?
Yeah, I couldn't quite see the way to make proper use of this
information either. I thought that might be because I'm under the
weather, but if nobody else is seeing one...
It's probably one of those things where if toybox had done it from the
start, it'd be fine, but as the installed base grows the cost of changes
to existing commands gets higher. :P
Rob
P.S. I an wrestling with your help text processing issue as we speak,
hope to have the fix checked in today. And THEN I can cut the release...
_______________________________________________
Toybox mailing list
http://lists.landley.net/listinfo.cgi/toybox-landley.net
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
Loading...