[Toybox] Github thingy #408.

[enh]

On Thu, Feb 2, 2023 at 3:34 AM Rob Landley <rob at landley.net> wrote:
>
>
>
> On 2/1/23 11:13, enh wrote:
> > On Tue, Jan 31, 2023 at 9:11 PM Rob Landley <rob at landley.net> wrote:
> >>
> >> Replying to https://github.com/landley/toybox/issues/408#issuecomment-1410711619
> >> here instead of the list because design discussions in github issues comments
> >> tend to get lost (or at least I can't easily find 'em again 6 months later):
> >>
> >> Patch applied. Note I'm unlikely to catch regressions introduced into pending,
> >> at least not in patches from you to pending, or from the person who wrote a
> >> thing that's in pending. Those get applied without much (if any) review because
> >> I tend to get sucked into long tangents far too easily otherwise. (The point of
> >> pending is it all gets a properly thorough review later, and well-meaning
> >> patches from known actors are unlikely to make it measurably worse in the meantime.)
> >
> > this is about vi? yeah, part of me regrets enabling that, but it is by
> > far the most requested toy.
>
> That's good feedback for me prioritizing work, actually...

yeah, sorry, i probably should have mentioned this earlier. if i
haven't said, i've made things worse in Android U by giving in an
adding the symlink. prior to that you have to `toybox vi`, but enough
people (from different companies) said "sure, it's broken, but half an
eye is better than no eye" that i added the symlink anyway. which of
course has done nothing to reduce the complaints :-)

> > mksh is good enough as a shell (and, as
> > i've said, almost all the complaints there are about the interactive
> > side of things --- "can you improve the line editing?"),
>
> I've been holding off in _implementing_ line editing in toysh because once I do
> people will start using it and sending me "yes, I know" bug reports. :)
>
> That said, it's getting close...
>
> > but cat is
> > not much of an editor. that's part of why i'd like to just have either
> > a simple gap buffer or a trivial block with the gap always at the end.
> > it's way easier to reason about/hack on, and thus much more amenable
> > to drive-by improvements (which i fear is all that vi's likely to get
> > any time soon).
>
> Eh, it can still change...
>
> > it's particularly sad to me that toybox vi is the same number of lines
> > of code as fuzix's "vile", but has less functionality and more bugs.
> > but it seemed like you were also attached to the "but what if i need
> > to edit 16GiB files on systems with large address space but small
> > ram?!" that got us to this YAGNI implementation in the first place?
>
> Part of what I need to do is refamiliarize myself with what all the vi commands
> _are_. I use maybe 10% of them tops. (And this despite having taught a chapter
> on vi in the "intro to unix" course I gave at acc many moons ago. I remember it
> _has_ mark-and-jump but not how to do it. I want to say backtick is involved?)

i think that's the way to do it, though --- implement the subset
people are actually using, as they ask for it. (like you, i know that
stuff is there, but can't remember it and don't use it.) this is also
why i'd like the implementation to be _simple_ rather than _clever_
--- so more people can contribute the 10% they use. (especially the
myriad movement commands!)

> >> Pretty much everything that's left in pending is its own nontrivial project to
> >> properly clean up and promote, or I'd have done it by now, and I don't want to
> >> mess with them much until I can set aside appropriate blocks of time/energy to
> >> FINISH them.
> >>
> >> Some aren't _big_ projects: telnet/tenetd I want to test interoperability with
> >> other server/clients. For tftp/tftpd I also one to test at least one real user
> >> like qemu's netboot, except the IBM mainframe "enterprise" clowns who hijacked
> >> the project and drove off Fabrice Bellard back when KVM became a thing replaced
> >> the simple "-bootp" command line option (http://etherboot.org/wiki/qemu) with
> >> some procedure involving feeding json into virtfs
> >> (https://www.kraxel.org/blog/2021/09/vm-network-boot/) and I need to build a
> >> sufficiently old qemu version that it's NOT CRAZY to test this.
> >
> > (i think both telnet and tftp are sufficiently niche these days that
> > "implements the absolute basics" is enough. i haven't heard any
> > complaints from the [niche!] users i'm aware of since you last saw
> > patches.)
>
> Indeed, but that's also why I haven't prioritized them. :)
>
> (Of the two, tftp gets used more in embedded systems because of bootp. Telnet's
> kinda dead-ish because there's not much room between netcat/microcom and ssh,
> but it's still there in posix and does serve _a_ purpose...)
>
> >> Some are design issues: tcpsvd doesn't share code with netcat and isn't inetd,
> >> it's an otherwise obscure UI that Denys Vlasenko was fond of so added to
> >> busybox, which got copied from there.
> >>
> >> Some are just "I've never used bootchartd and need to figure out how to tell
> >> what success looks like."
> >>
> >> In the case of useradd and friends, the project is the lib/password.c rewrite
> >> and the _blocker_ is making test infrastructure to properly regression test it
> >> in a known environment it can trash, although I suppose I _could_ test it in a
> >> deboostrap chroot before mkroot's ready? Hmmm...
> >>
> >> Anyway, feel free to close this issue if it's working for you, lemme know what
> >> to fix next if not...
> >
> > (closed anyway on the basis of "that was a feature request, feature
> > now implemented, anything else is bug reports, and i'll send those to
> > the list".)
>
> Yay.
>
> Sigh: lemme finish the ls --sort changes and cp -s changes (which are blocking
> adding install -T), get toysh running the test suite under mkroot (or at least
> finish the "read" and "command" builtins), test and check in the lib/passswd.c
> rewrite (which incidentally lets MUCH more of defconfig build/pass with bionic),
> circle back to get diff finished, and THEN maybe I can open the vi can of worms?
> (Which puts it before git, dd...)
>
> Rob