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

[Rob Landley]

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?

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

Seriously,that's what LOCALE=C _should_ emit. :P

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

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

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

> 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