On Sun, Aug 25, 2019 at 5:27 PM Rob Landley <[email protected]> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
