[Toybox] [PATCH] date: more test cleanup.

enh enh at google.com
Wed Feb 13 09:12:15 PST 2019


On Wed, Feb 13, 2019 at 4:11 AM Rob Landley <rob at landley.net> 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


More information about the Toybox mailing list