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

[enh]

i've sent a patch ("[PATCH] Fix find(1) after
c26870dab3462c6176936384b090df6b9ba46dee") to fix this bug plus
another bug i found in find error reporting while poking about.

On Mon, Aug 26, 2019 at 9:20 PM enh <enh at google.com> wrote:
>
> 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