[Toybox] JOE

Thu Jan 23 14:08:24 PST 2020

On 24/01/20 08:14, toybox-request at lists.landley.net wrote:

> Message: 2
> Date: Thu, 23 Jan 2020 11:40:19 -0600
> From: Rob Landley <rob at landley.net>
> To: toybox at lists.landley.net
> Subject: Re: [Toybox] [PATCH] vi: don't exit on ^C or ^D.
> Message-ID: <392265de-ba1a-e0bc-5e16-4bef308df040 at landley.net>
> Content-Type: text/plain; charset=utf-8
> 
> 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). 

JOE is being maintained by its original author Joseph Allen, plus all of 
the people who send bug reports, feature suggestions and patches to the 
project web site. JOE is hosted by SourceForge.net and its source code 
is controlled under Mercurial, and there are not many packages that can 
still say that!

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
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
> 
> 
> ------------------------------
> 
> End of Toybox Digest, Vol 99, Issue 24
> **************************************
> 