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

[enh]

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?

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,
though it's definitely unfortunate that there are a few BSD/GNU
wording differences.

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.

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

> Toybox says "bad $THINGY" wherever possible. I have been attempting to learn
> japanese for 3 years and have a vocabulary of _maybe_ 30 words, I don't expect
> other people to learn english just to _use_ toybox.
>
> (That said, I have no mechanism for translating the --help text designed. It's a
> vague post-1.0 "huh..." that I vaguely hope to leverage the man page
> infrastructure for. I could also swap out generated/help.h with another file at
> build time, or do something at runtime. I want something non-intrustive and
> easily ignored when you're not using it, but also robust enough it's not gonna
> segfault and be an attack vector if you feed it a misformatted file...)
>
> Seriously, I could spend _years_ more on polishing this stuff full time. :P
>
> > (I still wish we had a regex match version of testing/testcmd, but I'm
> > still not really sure what it would look like.
>
> I pipe output through sed to get that (as your patch does). I can try to
> genericize it a bit if you'd like? But again: I don't want to depend on help
> text, the tests should run against a non-english localized libc. (I specify
> LOCALE=C sometimes, but I don't believe that's EN_US.)
>
> I haven't done anything with this yet because bash has a ~= operator I plan to
> implement it in toysh, and my big "fluff ouf the test suite" pass is planned for
> after I get that in and can depend on a bash-like shell being available to run
> the tests.
>
> > All I care about here is
> > that we did report that there was a problem with dir/looper...)
>
> The tests don't have to be that verbose, run them with V=1 and they say what
> line they ran, and the files under generated/testdir aren't deleted if the test
> aborts. That's usually enough to reproduce the issue on the command line (and
> add in that the test script is human readable shell script by design. The test
> ID is primarily just to let you help find the test so you can pick out what went
> wrong. It could be "test1", "test2", "test3" and a few of the closely related
> ones are...)
>
> Rob