[Toybox] [PATCH] vi: don't exit on ^C or ^D.

[Rob Landley]

On 1/22/20 10:53 AM, dmccunney wrote:
> On Sat, Jan 18, 2020 at 2:34 AM Jarno Mäkipää <jmakip87 at gmail.com> wrote:
>>
>> I looked into ex commands little bit more, All the edits seem to be
>> line based or correct me if im wrong?
> 
> No, that's correct.  Ex is a line editor.
> 
> AT&T Unix provided vi, ex, and view.  Vi  was the full screen editor.
> Ex was a line editor.  View was a read-only file viewer.

AT&T didn't provide vi, Bill Joy wrote it at Berkeley.

> All three were links to the same underlying executable.  It looked at
> the name it was called by when invoked and assumed the proper
> personality.
> 
> Back when, AT&T divested itself of Unix System Laboratories, and USL
> was bought by Novell.

Glossing over the USL lawsuit where AT&T was found guilty of sucking in BSD code
without attribution, even stripping off the copyright notices.

https://www.bell-labs.com/usr/dmr/www/bsdi/bsdisuit.html

(That's also why Bill Gates dumped the Unix port Paul Allen had commissioned on
their consulting partner SCO and washed his hands of it: he found Microsoft's
xenix code had been copied without attribution into System III, and didn't think
1986 Microsoft could take AT&T in a legal fight, so he exited the Unix business
entirely. AT&T also went around and strong-armed companies to switch from a BSD
base to a System V base, which is why SunOS was replaced with Solaris and so on.
Robert Young wrote about that in "Under the Radar", everybody was pissed at the
time because the _technology_ was worse...)

> After then CEO Ray Noorda was pushed out by
> Novell's board, the effort became part of Caldera.
> (https://en.wikipedia.org/wiki/Caldera_(company))

And then he got altzheimer's allowing a con artist to take over "the canopy
group", acquired SCO's Unix business (allowing the original company to rebrand
itself Tarantella and focus on doing an app instead) because Caldera thought
they could use SCO's unix reseller distribution channel to convert that customer
base over to Caldera Linux (spoiler: nope), but when a $10-ish million company
acquires a $100-ish million annual gross revenue stream that's net LOSING money
each year (support cost more than income, that's why it was going so cheap) and
then goes "I'll just strip it down until it's profitable" and instead DISMANTLES
the entire acquired business without it ever becoming profitable at any step
along the way (because if was that easy original SCO would have done it instead
of selling), and then the scam artists running the show follow the classic
"dying business models explode into a cloud of IP litigation" model and sue
everybody they can despite AT&T having passed the hat one last time selling
"perpetual" licenses to the IP (Amendment X I believe) and thus I had to work on
http://www.catb.org/~esr/hackerlore/sco-vs-ibm.html and
http://www.catb.org/~esr/halloween/halloween9.html and such for a couple years
fighting them off...

> Caldera released the source code for traditional vi under a BSD
> license in 2002.  It's available here if you want to see what they
> did: https://ex-vi.sourceforge.net/
> 
> https://sourceforge.net/projects/ex-vi/ is a better link for downloads.

I prefer not to read the code of other implementations while writing a new one
so I don't get accused of copyright infringement and license contamination. (I
do, however, read the man page and run the host version on whatever Linux distro
I'm currently running under strace and analyze their output and such when
necessary.)

> I learned vi under AT&T Unix System V Release 2.

I was 12 years old when that came out.

> I have Vim, but for
> the use I make of it, it might as well *be* vi.  I have never needed
> all the bells and whistles Vim added.

Years ago I taught an Intro to Unix course from a textbook that had a chapter on
vi and learned all _sorts_ of weird little things I'd never known it could do...
and promptly forgot most of them again because I just never use them.

As with Perl and C++, everybody uses a different subset of the giant pile of Too
Much Stuff...

> I'd be *delighted* by an Honest-to-$DEITY vi in Toybox.

Technically, original vi didn't let you cursor around in insert mode (largely
because it predated cursor keys, that's why the two modes and all the in-band
signalling for navigation), and that's why Ubuntu screwed up "vi" with that
/etc/vim.tiny thing that ACTIVELY DISABLES that ability, so you have to "sudo ln
-sf vimrc /etc/vim/vimrc.tiny" on each new debian install to fix that.

Busybox never had that problem. (It had
http://lists.busybox.net/pipermail/busybox/2008-October/067372.html with serial
consoles but I fixed it.) And nothing in Linux did before about 2010 when
somebody apparently decided everybody should use Emacs and he was gonna break vi
until they did. (Yes, I can type "vim" instead. But I won't, and shouldn't have to.)

My own todo list item for a text editor was to make a generic engine I could
implement vi, emacs, nano/edit, and joe (wordstar) keybindings on top of (and
MAYBE share plumbing with less and watch). I was mostly worried about the
lifetime rules for large text blocks on memory-constrained and nommu systems
where large contiguous allocations become rapidly problematic; I was thinking
copying data into .swp files so I wasn't depending on the original mmapped file
not to change out from under me but I also wasn't needing to keep a 2 gigabyte
linux-kernel mbox file in memory because I was searching around for that one
email (yeah I should use "less" instead, but it's terrible for this sort of
thing and see above about wanting shared plumbing), and hence the "array of
pointer+length to block-of-text" representation, but not one BIG
array-of-pointer because just the line index tracking on my inbox mbox that goes
back to 2013 probably takes more memory than my Turtle board has (it's 1.3 gigs,
wc says just under 20 million lines, so *8 and the box has 256 megs _before_ you
boot the kernel...).

It's one of those things where "what counts as pilot error" is a judgement call
and you need an analysis of usage patterns, and more to the point I needed to
check what the kernel did for MAP_PRIVATE mappings where another process changes
a part of the file that this process hasn't faulted in yet BUT it's still
covered by the mapping, and maybe madvise comes in here...? Yes only a 64 bit
system could reliably map full files and 32 bit would need its own codepath, and
nommu would also need its own codepath, and maybe only 64 bit with mmu would get
properly reliable behavior and the others would just get best effort...

But I didn't get around to it in time and the decision was taken out of my
hands, so it goes on the "dead idea" pile along with implementing screen.

*shrug* Happens. Got my hands full with the shell at the moment. (WHY is CLOEXEC
vanishing on fd 5? Why is fd 5 magic and it's not doing it on any of the other
fds? I've reproduced it under qemu and am sticking printk() calls into the
kernel and it currently looks like calling pipe2() is making it vanish for NO
APPARENT REASON (the fd ALREADY EXISTS, how is pipe2() taking CLOEXEC off an
_existing_ FD?), but have been mostly busy with j-core stuff this week.)

Rob