On Mon, Mar 18, 2024 at 6:04 AM Rob Landley <[email protected]> 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...
_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net
