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

[enh]

On Mon, Aug 26, 2019 at 9:17 PM enh <enh at google.com> wrote:
>
> On Mon, Aug 26, 2019 at 7:30 PM Rob Landley <rob at landley.net> wrote:
> >
> > On 8/26/19 10:48 AM, enh wrote:
> > >> $ ./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).
> >
> > When you say "shows more entries"... in theory it's listing the same entries,
> > it's just some of them are in error messages and some are in output. If that's
> > correct, I can suppress the error messages and just show the files for ls, and
> > show the ??? version for ls -l.
>
> yes, sorry, that's what i meant: "more entries on stdout". i think the
> (lack of) alphabetical order was confusing people too. you don't think
> to scroll back for something that alphabetically should be visible
> near the end.
>
> > >> 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 :-)
> >
> > Hmmm...
> >
> > Ok, I took at swing at this. Hit a minor asethetic design issue: symlink colors
> > are funky. I have "link is always light blue, but destination is red if it's not
> > there, and the color of whatever it is when something's there".
> >
> > But the gnu/dammit version has the link name red when it's a broken link, which
> > comes up here because a link it can't readlink() stat is red (even when it
> > points to something).
> >
> > This seems odd to me (the _link_ didn't change when it breaks or unbreaks, what
> > it points to did), but if you care I can implement that?
>
> _i_ have never used color ls, so i'll be the last person to have an
> opinion here. but i'll let you know if i hear anything.
>
> > Anyway, just pushed a first stab at making it suck less obviously.
>
> cool. i'll give it a go. (strictly i'm off sick, but i haven't been
> able to refrain from checking mail...)

this comment had me worried:

"Tweak DIRTREE_STATLESS so it returns zero stat for any error (I'm testing
that dev, ino, and blksize are all zero), and fill in file type from readdir()"

and indeed, this breaks one of the find(1) tests i added. (and is how
we reopened this conversation about ls(1) --- the difference between
find which only ignores ENOENT and ls which ignores more.)

> > Rob