[Toybox] Github thingy #408.

[Rob Landley]

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

> 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?)

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