[Toybox] hexdump tests.

[Rob Landley]

On 3/15/24 09:58, enh wrote:
> On Thu, Mar 14, 2024 at 9:25 PM Rob Landley <rob at landley.net> wrote:
> > 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?

NOSPACE already doesn't reset, I've been doing shell prefix assignment to set it
for individual commands, ala:

  $ NOSPACE=1 bash -c 'env | grep NOSPACE'
  NOSPACE=1
  $ echo -n $NOSPACE
  $

If I just NOSPACE=1 on its own line it should apply to all the tests in the
current script, then clean up at the end because each test script runs as a
(child process) with its own environment.

And that's probably correct here because diff -b ignores changes in the AMOUNT
of space but not the EXISTENCE of space, so "a b c" and "abc" still wouldn't
match, which is what I was worried about. (I thought -b yanks space, but instead
it normalizes it.)

> 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).

Sure, but that said some tests _DO_ care about the exact amount of whitespace
(are columns aligned), or tabs vs spaces.

> (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...)

It mostly comes up when I complain we've got FOUR hex dumpers that share no code
(it's the fourth, you added the third with xxd, posix od and my hexedit were the
first two), but the recent revisit tipped me over into "alright, I'll clean it
up..."

The problem is "dump hex" isn't a big enough job that pulling it out into a
library function that can be shared is really a win. It's another one of those
"the fighting is so vicious because the stakes are so small" things. Maybe if I
could genericize the "show hex in 4 digit groups, now do octal!" variants into
some sort of engine... but I worry that the glue to call the engine would be
bigger than any savings.

*shrug* Punt that for a potential post-1.0 cleanup pass, and lump it in the
meantime...

>     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.

Yes I saw your email in the other thread about pending not being granular
enough, but didn't really have anything coherent to say in response? I see
pending as an unfinished todo heap I need to drain, and I feel bad for not
cleaning it up fast enough. Doing non-cleaning work there is like organizing
trash piles. Attempting to categorize the bulk wasn't an unambiguous win even
for toys/ which is _intended_ to keep growing rather than shrink, so adding it
to pending doesn't appeal. I don't really want spend architectural design cycles
on scaffolding that gets torn down again.

Rob