[Toybox] hexdump tests.

[enh]

On Fri, Mar 15, 2024 at 2:06 PM Rob Landley <rob at landley.net> wrote:

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

i know what you mean, but at the same time, i'm struggling to thing of a
single case i've been involved with where the "upstream" tool hasn't
screwed me over by doing something stupid sooner or later...

CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION=1? so we trust ourselves but
no-one else? :-)


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

od and hexdump are weird there in that the former lets you express quite a
large variety of different dumps, and the latter (i think) pretty much
anything. i have wondered whether the others can't mostly be written in
terms of hexdump. (xxd still has all the reverse stuff, but as long as
no-one else does, that's not duplication.)


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

yeah, like you say, these are some of the simplest commands anyway. i'd be
a lot more worried if we had four seds or four shells :-)


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

indeed.

i think the only half-way practical idea i had was "keep pending but just
switch to a much scarier name". because, to be fair to the confused, in
english "pending" _can_ legitimately mean "almost there". whereas your
whole point with pending is "i actually have _no_ idea how close this is
yet". if i _had_ to do something today, renaming "pending" to
"experimental" is probably where i'd land. but then this would look rather
suspect over in the aosp build system:

    "toys/pending/diff.c",
    "toys/pending/expr.c",
    "toys/pending/tr.c",
...
    "toys/pending/brctl.c",
    "toys/pending/getfattr.c",
    "toys/pending/lsof.c",
    "toys/pending/modprobe.c",
    "toys/pending/more.c",
    "toys/pending/stty.c",
    "toys/pending/traceroute.c",
    "toys/pending/vi.c",

:-)

oh, btw, i realized next time i tried why i've struggled to make myself do
`toys/*/foo.c` ... it's because the shell won't tab-expand through the
`/*/` even if only one directory matches, and i tab complete all the time
:-(


> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20240315/e1aade65/attachment-0001.htm>