On Wed, Feb 13, 2019 at 4:11 AM Rob Landley <[email protected]> wrote: > > On 2/13/19 12:05 AM, enh via Toybox wrote: > > Add the SKIP_HOST=1 for the POSIX inputs to -d that coreutils doesn't > > support. > > Still not quite sure what the right thing for SKIP_HOST to do is. (It really > indicates "this test isn't portable", although whether it's busybox or debian > failing is more detail than I usually want to record, that's not the intended > purpose of this test suite. It would be _nice_ if there was a general purpose > command line tester, but scope creep...) > > I can add test if host is toybox, but [ "$(basename $(readlink -f > "$CMDNAME"))" > == toybox ] won't catch standalones, checking $CMDNAME --version output for > "toybox" won't catch sed or false, and you can already test toybox within the > build anyway... > > I can make the test attempt anyway and replace FAIL with SKIP in the output, > but > if the failure mode is "hangs" or "tries to dirty terabytes of memory until > the > OOM killer triggers".... > > And thus it's doing what it's doing at the moment, which still seems wrong...
yeah, which is why i've been going for `SKIP_HOST=1` plus a comment explaining why. good enough workaround in the meantime, and keeps the knowledge for if/when we have better infrastructure. what i miss more is not having a good way to check for expected errors, especially given that we're making little/no effort to match error messages. would be good to have some kind of "i expect command c to fail with exit code x and stderr output that matches regex r" utility. > > Fix some comments now Rob's pointed out that the "weird" format was just > > POSIX with implicit CCYY or CC. (I was confused because coreutils rejects > > them [as it rejects all POSIX input to -d], but busybox does accept them, > > but interprets them differently, as explained in the test comments.) > > Hmmm... busybox is probably right that it should use the current year. yeah, but i'm not convinced that a version of date that works with the two TZs will look much like the current code (in particular: i suspect that we want to use time_t rather than struct tm), so i plan to look at that first. (for values of "plan" that involve me working breadth-first and going off to see what the problems with find are and whether there are any more sed problems...) > Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
