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

[Rob Landley]

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.

>> 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?

Anyway, just pushed a first stab at making it suck less obviously.

Rob