[Toybox] [PATCH] find.test: fix test expectation for BSD libcs.

[enh]

On Sun, Aug 25, 2019 at 5:27 PM Rob Landley <rob at landley.net> wrote:
>
> On 8/20/19 4:44 PM, enh wrote:
> >> Seriously,that's what LOCALE=C _should_ emit. :P
> >
> > agreed. (we used to joke that en_NJ [for New Jersey] should do this.)
> >
> > but forcing the locale to en_US.utf8 is good enough for our testing
> > purposes, with the exception of [rare] cases like this where the
> > strings differ slightly.
>
> Assuming en_US.utf8 is installed on the machine, but yeah we can spec that as a
> prerequisite for running the test suite.
>
> >>> though it's definitely unfortunate that there are a few BSD/GNU
> >>> wording differences.
> >>
> >> And probably musl in there too (which is increasingly important in the
> >> docker/container world; alpine's their default "small" distro)...
> >
> > i'd assume musl just copied glibc's strings?
>
> https://git.musl-libc.org/cgit/musl/tree/src/errno/__strerror.h
>
> >>> (my specific worry in this case is that i assume that eventually
> >>> DIRTREE_STATLESS will return errno in struct dirtree because other
> >>> potential users -- like ls(1) -- want more control, at which point
> >>> find(1) will likely be in charge of reporting its own errors based on
> >>> dirtree errno values rather than necessarily the thread-local errno.
> >>
> >> I'd make that its own flag, and let's burn that bridge when we come to it.
> >>
> >> But tell me more about this use case? Why does ls need more control of its error
> >> messages? (I believe you, I just want to understand the goal you're trying to
> >> achieve here.)
> >
> > i haven't actually tried to write this yet, so i reserve the right to
> > be wrong, but ... i think that ls cares about the difference between
> > stuff like EPERM/EACCES (where it should just do the whole ??? thing
> > we've seen the GNU one do) and anything else, where it should just
> > report the error.
>
> Oh, I reproduced a directory full of ??? output: chmod 444 dirname:
>
> $ ls dirtest -l
> ls: cannot access 'dirtest/three': Permission denied
> ls: cannot access 'dirtest/one': Permission denied
> ls: cannot access 'dirtest/two': Permission denied
> total 0
> -????????? ? ? ? ?            ? one
> -????????? ? ? ? ?            ? three
> -????????? ? ? ? ?            ? two
> $ ./toybox ls -l dirtest
> ls: dirtest/three: Permission denied
> ls: dirtest/one: Permission denied
> ls: dirtest/two: Permission denied
> total 0
>
> I'm not sure we're worse?
>
> $ ./toybox ls dirtest
> ls: dirtest/three: Permission denied
> ls: dirtest/one: Permission denied
> ls: dirtest/two: Permission denied
> $ ls dirtest
> ls: cannot access 'dirtest/three': Permission denied
> ls: cannot access 'dirtest/one': Permission denied
> ls: cannot access 'dirtest/two': Permission denied
> one  three  two
>
> But that _is_ worse. Hmmm.

yeah, that's the specific case that folks have noticed; Android's / is
like that for non-root, so `adb ls` (which uses the adb protocol
directly) shows a lot more entries than `adb shell ls` (toybox).

> Possibly it should produce the -????????? output without the "permission denied"
> messages for -l, and just produce the filenames for ls. (And then append an ?
> for ls -F which the other one doesn't do but... :)

yeah, that's my feeling too. of course, since i'm always root, this is
very low down my list :-)

> Wouldn't it be nice if the posix committee still functioned? I hope its Jorg
> Schilling problem clears up someday. In the meantime we soldier on ignoring them...
>
> >> I've had error_msg() so multiple toybox commands produce a consistent error
> >> format, and it intentionally defers to libc for what the error message should be
> >> in the local language. But an environment variable so it can spit out the macro
> >> names for testing would be REALLY NICE. I very vaguely remember reading
> >> something about the ability to make it do that that years ago, but have no idea
> >> where or which "it" this was referring to...
> >
> > definitely haven't seen anything like that myself.
>
> It was back in college, so quite possibly SunOS had a way to do that.
>
> Rob