[Toybox] Command exit numbers.
enh
enh at google.com
Tue Jun 13 17:11:25 PDT 2017
On Tue, Jun 13, 2017 at 3:52 PM, Rob Landley <rob at landley.net> wrote:
> On 06/12/2017 10:49 AM, enh wrote:
>> On Sat, Jun 10, 2017 at 11:29 AM, Rob Landley <rob at landley.net> wrote:
>>> 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.
> 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
>
>>> 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
>
>> "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.)
>
>>> 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.
>
>>> *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
> Toybox at lists.landley.net
> 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.
More information about the Toybox
mailing list