On 06/12/2017 10:49 AM, enh wrote:
> On Sat, Jun 10, 2017 at 11:29 AM, Rob Landley <r...@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".

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@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Reply via email to