[Toybox] hexdump tests.

[enh]

On Thu, Mar 14, 2024 at 9:25 PM Rob Landley <rob at landley.net> wrote:

> Following up on commit cab0b6653827, the hexdump test suite is weird. For
> example, the first test has "simple\\n" when it means "simple\n" (which
> nevertheless somehow works for reasons I am loathe to examine at the
> moment, and
> I have a todo item to convert the various test arguments needing escapes to
> $'blah\n' arguments where the shell does it instead of washing it through
> echo
> inside the function, but that is a giant flag day change for some point
> where
> I'm facing a clean tree.)
>
> But the bigger problem is that TEST_HOST doesn't pass because debian's
> hexdump
> is doing something silly:
>
>   $ echo -e 'simple\n' | hexdump | sed 's/$/./'
>   0000000 6973 706d 656c 0a0a                    .
>   0000008.
>
> I.E. padding short lines with trailing spaces, because of course.
>
> I could make ours do that, or I could export NOSPACE=1 at the start o the
> test
> (since each one runs as a child process now meaning environment variable
> assignments won't persist into other tests)


or have a NOSPACE that _doesn't_ reset? i feel like most of the tools that
produce human-readable output have this problem otherwise: (a) upstream
often has a weird duplicative implementation that leads to bizarre behavior
and (b) they keep changing things (possibly without even noticing, since
it's whitespace).

(xxd, which has the `-r` option, seems like the partial exception, but even
there as long as xxd can consume any [text] input it's likely to be given,
i don't think it matters exactly what the text output's whitespace looks
like?)


> but that weakens the test, or maybe
> I could add a "NOTRAIL=1" that runs the output through sed 's/[ \t]*$//'
> or some
> such?
>
> Anyway, reviewing commands to promote them out of pending is a thing, and
> I'm
> trying close tabs rather than open more just now.
>

(i didn't even realize there was a hexdump in pending! missed that
somehow...)


> Rob
>
> P.S. In THEORY the chmod +x bit on tests/*.test is the equivalent of
> "pending",
> where "make tests" only runs the ones marked executable but you can still
> run
> them individually/standalone with "make test_commandname". In practice, the
> pending status of commands and the pending status of TESTS isn't a 1-1
> match up.
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20240315/32fb5d4a/attachment.htm>