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 <[email protected]> wrote: > > On Mon, Aug 26, 2019 at 9:17 PM enh <[email protected]> wrote: > > > > On Mon, Aug 26, 2019 at 7:30 PM Rob Landley <[email protected]> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
