[Toybox] hexdump tests.

[enh]

On Mon, Mar 18, 2024 at 6:04 AM Rob Landley <rob at landley.net> wrote:
>
> On 3/15/24 16:24, enh wrote:
> >     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...
>
> Yup. And yet...
>
> I'm thinking maybe strip _trailing_ whitespace? It's not user-visible and I
> can't think of an instance where it's semantically relevant. (LEADING whitespace
> is semantically relevant all the time, interstitial a lot too. But trailing
> generally shouldn't BE there...)
>
> > 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.

> >     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.)
>
> Yeah, it _seems_ like there's something I can do there, but I'm tired of being
> distracted by it.
>
> >     *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 :-)
>
> At the end of my tenure, busybox had FIVE shells, although that last one was my
> fault and two of them were the "xkcd standards" problem.
>
> 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? 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.

> Somebody then started hush as the "one shell to rule them all" replacement but
> work on it petered out. Not sure whose baby that was because the entire busybox
> community collapsed at about the same time: Erik Andersen ran a startup and got
> so overworked his marriage nearly collapsed, Manuel Nova's girlfriend died,
> Glenn McGrath tried a GPL enforcement action down in australia/new zealand and
> it left such a bad taste in his mouth he quit open source development entirely,
> Mike Frysinger started maintaining seperate for-profit forks of every project he
> touched and never pushing anything upstream which eventually resulted in the
> blackfin architecture (his dayjob) being declared dead and yanked from
> linux/arch and never even making it into qemu... And that's ignoring the whole
> uclibc->buildroot saga...
>
> *shrug* Hush dying was pretty minor in context: the busybox community imploded
> and I stepped in to prop up what I could until Bruce went "you, volunteer who is
> mopping the floors, you're doing it wrong, do it MY WAY, I have _seniority_ and
> you've been doing everything in my name all along anyway whether you know it nor
> not"...
>
> Anyway, before all that happened I printed out the bash man page into a 3 ring
> binder to read on the bus and started my own "one shell to rule them all",
> bbsh.c, and work ended on that when bruce chased me off busybox. Denys removed
> it pretty early on in his tenure, but as far as I'd gotten was what was checked
> in to pending until the current round of shell work started...
>
> >     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".
>
> I need to clean it all up. I just haven't quite gotten my groove back
> post-pandemic and people keep submitting distracting bug reports for the
> existing code. (The downside of having users: they find stuff.)
>
> > 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!".

> > if i _had_ to do
> > something today, renaming "pending" to "experimental" is probably where i'd
> > land.
>
> Which has the same "git log/annotate doesn't follow renames by default" problem
> that moving everything BACK out of toys/*/blah.c into toys/blah.c has. (And
> there's no short option to do it either.)
>
> > 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",
> >
> > :-)
>
> It _is_ somewhat suspect. But then so is mkroot enabling ifconfig and sh.
>
> > 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 :-(
>
> That is a downside, yes.
>
> However, if everything was in one big directory, none of it would be in pending
> or example...

yeah, to be clear: i just meant all the default 'y' stuff.

> Rob
>
> P.S. I need to do more work on the shell conditional execution stuff, because:
>
> $ export ZAP=42
> $ echo ${ZAP=$(echo potato >&2)then}
> 42
> $ echo $ZAP
> 42
> $ unset ZAP
> $ echo ${ZAP=$(echo potato >&2)then}
> potato
> then
> $ echo $ZAP
> then
>
> Means I can theoretically go ${VERSION:=$(git describe)} without the command
> getting run when it isn't needed, but right now bash gets that right and toysh
> doesn't yet...