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

[Rob Landley]

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.

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