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

[enh]

On Thu, Aug 15, 2019 at 10:21 AM Rob Landley <rob at landley.net> wrote:
>
>
>
> On 8/15/19 11:00 AM, enh wrote:
> > On Thu, Aug 15, 2019 at 2:00 AM Rob Landley <rob at landley.net> wrote:
> >>
> >> On 8/14/19 8:06 PM, enh via Toybox wrote:
> >>> glibc says "Too many levels of symbolic links", but BSD says "Too many
> >>> symbolic links encountered".
> >>
> >> And if you're running the test against a localized chinese libc the error
> >> message is something else entirely. Don't depend on it. I write tests to check
> >> the error return code, or to notice that there WAS something written to stderr
> >> (without caring what it is, just that it's nonzero length). I'm not happy with
> >> this fix because of that: if you depend on specific error message text it
> >> probably won't work in korea.
> >
> > isn't our fix for locale issues to control the locale, which is just
> > something we should do globally for all the tests?
>
> Will a chinese localized libc output english error messages if they set an
> environment variable?

i don't speak Chinese, but here's glibc+Korean:

~$ LANG="ko_KR.utf8" ls missing
ls: cannot access 'missing': 그런 파일이나 디렉터리가 없습니다

so English error from ls(1) but Korean strerror(3) output.

assuming you consider "file" (파일) and "directory" (디렉터리) to be korean
words, of course :-)

(the mac, which is the other place i'd expect to see this, doesn't
seem to do anything. the same ls test always outputs in en_US.)

> > we've definitely had bugs before where we've output the wrong errno
> > value, so i think it's a mistake to pretend we're not interested in
> > the actual text, because outputting the _correct_ error is as
> > important to the end user as outputting any error. i think rigid
> > control of the test environment's locale is the right way to go,
>
> I'm willing to be overruled on this if you feel strongly. I don't know enough
> here. Mostly I've been testing "does it spit the filename I fed it back at me"
> sort of thing.
>
> Hmmm... is there a way to get it to spit the ERRNO macro name out? (The actual
> error number varies by architecture sometimes, but the errno macro name won't. :)

no, iirc there's some talk on the POSIX list of standardizing the
conversions to/from signal names, but not errno.

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

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

> > anyway, new patch sent that breaks the test into two (which is a good
> > idea anyway) and accepts any error message at all for the error case.
>
> Applied.

thanks. that's good enough for me to keep moving.

> This problem needs design work.
>
> > (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.

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

> > but this patch is enough to get the tests passing on Android again,
> > which lets me sync toybox again, so it'll suffice for now.)
>
> Sigh. Jeff Dionne (the creator of uclinux) is pointing me at a thing called
> "FreeMind" which can apparently turn todo lists into dependency graphs. I am
> dubious, but need to find something to manage this mess and allow some form of
> collaboration on it...
>
> "Collate todo lists" is a perpetual todo list item.
>
> Rob