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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
