[Toybox] hexdump tests.

[enh]

On Sun, Mar 24, 2024 at 1:40 AM Rob Landley <rob at landley.net> wrote:
>
> On 3/22/24 15:02, enh wrote:
> >> > CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION=1? so we trust ourselves but no-one
> >> > else? :-)
> >>
> >> I _don't_ trust myself, and I'm not special. (That's policy.)
> >
> > yeah, but that's why i suggested
> > CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION --- that way we can say "we
> > can't make hard assertions about the _host's_ whitespace, but we can
> > still make hard assertions about _ours_". if we just canonicalize all
> > the whitespace all the time, we can't (say) ensure that columns line
> > up or whatever.
>
> Or we could just "NOSPACE=1 TEST_HOST=1 make tests" if that's the test we want
> to run...?

it's not though. that's my point. there are several cases:

1. testing toybox --- we know what whitespace we're expecting to
produce, and want tests to protect against regressions.

2. testing host tools --- we _don't_ have control over what whitespace
the host produces.
  a) in some cases we manually mark individual tests to show "we don't
care about host whitespace for this test case".
  b) sometimes this applies to _all_ the tests for a toy.

we're talking about case 2b here, which is currently the
least-well-supported variant.

i think we're talking at cross purposes because _i'm_ talking about
variables set _within the tests, by the tests themselves_ and you're
talking about variables set on the command-line, which i don't think
make any sense here, because we're talking about properties of the
individual tests/commands.

(unless you really do want to say "there's absolutely nothing we can
do about host whitespace, so give up completely", which i think has
yet to be proven that it's _that_ bad. but there are commands where
having a test that says "this whitespace -- that toybox produces -- is
reasonable [but as long as the non-whitespace matches, and there's
_some_ whitespace everywhere we have whitespace, we'll accept any
whitespace from the host tool]".)

> >> Erik did lash (lame-ass shell) to be tiny, Ash was the bigass lump of complexity
> >> copied out of debian or some such and nailed to the side of the project by that
> >> insane Russian developer who never did learn english and communitcated entirely
> >> through a terrible translator program (so any conversation longer than 2
> >> sentences turned into TL;DR in EITHER direction, he was also hugely territorial
> >> about anybody else touching "his" code), and msh was the minix shell mostly used
> >> on nommu systems.
> >
> > did lash _stay_ tiny?
>
> Yes, but it was also borderline unusable.
>
> > i feel like the trouble with projects like that
> > is usually that no-one can agree on what's necessary versus bloat, so
> > you trend towards just being a bad implementation of whatever. iirc
> > inferno had _two_ different "tiny" shells.
>
> Erik implemented something tiny for his own personal use, and ignored everybody
> else who tried to add stuff to it.
>
> When Erik moved on, I studied it. When I moved on, Bernhard removed it:
>
>   https://git.busybox.net/busybox/commit/?id=96702ca945a8
>
> >> > 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".
> >>
> >> Linux has drivers/staging but I didn't like that.
> >
> > yeah, "staging" also sounds very much like "nearly there!".
>
> The problem is motivated reasoning. We could call the directory
> instant_death_do_not_touch and people would still enable stuff in it to see if
> it worked for them. (And then ship it when it Worked For Them.)
>
> Rob