[conspire] vi (was: Re: Technical Interview Performance by Editor/OS/Language - Triplebyte Blog)

[Texx]

The Berkeley enhancements (Visual, csh and a number of other things) were
originally under /usr/ucb/bin

Michael is correct about vi being built on top of ex correctly.
For years the dot file for vi was actually .exrc
I do remember the command being "visual" and updating my "cashrocks" file
(.cshrc) "aliases" section.
Im trying to remember whether this was Unix v6 or v7.

I believe the code to Bills original vi was ALWAYS opensource as it was
developed on the university machines,
as was the original ingres db and a number of other things.

If I were to search for Bills original code, I would look in the BSD
archives rather than the LINUX.
By the time RedHat shipped in shrink wrap, I think the rewrite of Bills
code had already bun if not completed.

I know that with VIM uses a .vimrc file.  I dont know if "non vim vi" still
uses .exrc or what.
I never needed to mess with it, so I never checked.

I still had the vi alias in my dot files in v7.
I *THINK* it was BSD Tahoe when they just renamed visual to vi.

For those who dont know, this was Bill Joy, one co founder of "Stanford
University Networks" AKA: Sun Micro.

I note that after Unix v7, ATT started getting VERY interested in
backtracking to v6 with the BSD stuff removed
and then going down the parallel tracks of Sys3 & sys5.
My personal suspiction was that ATT was afraid the universities were
rujnning away with THEIR product and therefore
retreated to v6 without the BSD enhancements and built on those.

Interestingly enough, 2 competing projects at ATT gave us Sys3 & sys5.  One
did not evolve into the other.
I was supporting v7, BSD, S3 & S5 and had a hell of a time keeping them
straight.

Interestingly enough, the ATT "system" paths both DID include vi, but many
of the other BSD enhancements were not.
One of the things that drove me mad was that dump & restore were originally
removed from Sys3 & Sys5.
ATT told us that we should be doing backups with either dd or cpio.
ATT eventually caved in both S3 & S5 and dump & restore returned.
Finally S3 died and the S5 I was dealing with the most was Sunos-5 (AKA
Solaris2).
There was a Solaris 1 (Sunos4.1.4) but thats immaterial to the story.
By Solaris 2.4 (SunOs5.4) it was finally something that I could stand and
by Solaris 2.5 I actually liked it.

Starting with Solari7 7, they droped the two point but Solaris 7 was still
SunOs5.7.
They decided that the product looked more mature growing in full numbers
rather than decimals.
In Solaris 8, it was still .exrc


On Sun, Mar 10, 2019 at 1:50 PM Michael Paoli <
Michael.Paoli at cal.berkeley.edu> wrote:

> > From: Texx <texxgadget at gmail.com>
> > Subject: Re: [conspire] Technical Interview Performance by
> > Editor/OS/Language - Triplebyte Blog
> > Date: Sat, 9 Mar 2019 15:15:26 -0800
>
> > I learned visual (the REAL name for vi) from man vi.
> > The name vi came from the alias students were setting in their dot files.
> > Emacs is a better option than Microsoft but could use a better editor.
>
> "Real name" might depend on the "when".  I know little of vi - at least
> by any personal experience, before 1980.  By the time (1980) I was using
> vi, it was already well established on Unix in University of
> California environments (and likely some bit beyond?).  The command was
> vi (not visual - though visual may have remained as an additional hard
> link?), man page was vi(1), it was of course also a hard link to ex.
> As I recall (and I think various documents support), first - at least
> on Unix, there was ed, then ex, then visual mode was added to ex,
> from ex one would enter visual mode by typing:
> visual
> (and it still works that way)
> which could also be shortened to shortest unique abbreviation thereof:
> vi
> (but not v, as that's another command in ex/vi - the complement of g).
> vi[sual] mode in ex became so popular, that code was modified such
> that if it was invoked with arg0 being vi (and/or visual?), it would
> start in visual mode, and the hard link(s) for vi (and visual?) were
> added - so one could invoke it into visual mode from CLI by simply typing:
> vi [options and/or arguments, etc.]
> $ (cd /usr/bin && ls -onLid vi ex)
> 311624 -rwxr-xr-x 3 0 472216 Dec 30  2016 ex
> 311624 -rwxr-xr-x 3 0 472216 Dec 30  2016 vi
> $
>
> > I am not aware of any vi package with Bills original code.
> > It appears to have been completely rewritten in several versions
> including
> > vim and nvi.
> >
> > I don't know the current bad port tree well, so it might still be there,
> > but none of Bills code remains in either Deb or RPM trees that I can
> find.
>
> Some year(s) back ... not all that horribly long ago, ye olde classic
> vi became open sourced - I think most useful search term may be
> "classic vi".  I don't know that any linux distros (or BSD) have
> packaged it - but the source code should be out there ... *somewhere*.
> Also, not sure what license it was released under.
> Anyway, by the time classic vi was open sourced, vim and [n]vi (not to
> mention other clones) had long gone well beyond classic vi.
> About the last place I saw classic vi, was Solaris ... I think 10 (or maybe
> 9) ... before Solaris dropped classic vi and switched to vim.
> The BSD folks (or mostly from BSD) had by then already done a
> reimplementation of vi ... on BSD systems it *is* vi, ... just not
> "classic vi".  Beyond BSD it's often/typically nvi, but can also be
> configured to be or be installed as vi (at least for most linux
> distributions
> that bother to have it available at all).
> The design goals of [n]vi were essentially a feature-for-feature,
> bug-for-bug reimplementation of vi (with of course source code not being
> so encumbered to conflict with release under, e.g. BSD, or similar
> licensing).
> So, [n]vi is *very* close to classic vi in functionality.  Anyone who's
> fingers/brain are used to flying through classic vi with great efficiency
> and speed, will be highly at home on [n]vi ... not so with vim.
> The number of functional differences between [n]vi and classic vi are
> *very* small and minimalistic ... would rather expect that from
> the BSD folks :-) ... they also avoid lots of bloat in, e.g. tar, cpio,
> pax, ... whole lot 'o cruft/bloat they just don't add.  That's often
> a very good thing. [n]vi is even much smaller that vim.tiny - which weighs
> in at about twice the size/bloat of [n]vi.  Let's see ...
> $ ls -on /usr/bin/vi /etc/alternatives/vi /usr/bin/nvi /usr/bin/vim
> /etc/alternatives/vim /usr/bin/vim.basic /usr/bin/vim.tiny
> lrwxrwxrwx 1 0      12 Jan  7  2013 /etc/alternatives/vi -> /usr/bin/nvi
> lrwxrwxrwx 1 0      18 Jan  7  2013 /etc/alternatives/vim ->
> /usr/bin/vim.basic
> -rwxr-xr-x 3 0  472216 Dec 30  2016 /usr/bin/nvi
> lrwxrwxrwx 1 0      20 Jan  7  2013 /usr/bin/vi -> /etc/alternatives/vi
> lrwxrwxrwx 1 0      21 Jan  7  2013 /usr/bin/vim -> /etc/alternatives/vim
> -rwxr-xr-x 1 0 2413032 Sep 30  2017 /usr/bin/vim.basic
> -rwxr-xr-x 1 0 1062744 Sep 30  2017 /usr/bin/vim.tiny
> $ echo $(lsb_release -d) $(uname -m)
> Description: Debian GNU/Linux 9.8 (stretch) x86_64
> $ ls -on /usr/bin/emacs /etc/alternatives/emacs /usr/bin/emacs24-x
> lrwxrwxrwx 1 0       18 Nov  5  2015 /etc/alternatives/emacs ->
> /usr/bin/emacs24-x
> lrwxrwxrwx 1 0       23 Jan 18  2013 /usr/bin/emacs ->
> /etc/alternatives/emacs
> -rwxr-xr-x 1 0 15759624 Sep 11  2017 /usr/bin/emacs24-x
> $
> What (very slight) functional differences between classic vi and [n]vi?
> In all my years using classic vi, and [n]vi, I think these are all that
> I've noticed:
> o line length limit of 1022 characters in classic vi (written in C,
>    presumably 1024 byte array, 1022 characters text max + newline +
>    terminating null for C string = 1024 characters - no such limit
>    in [n]vi
> o classic vi craps out (drops to ex mode?  Or I think it more just dies
>    some type of death and exits) - if one ever has a display line that
>    can't fit on the total window size - e.g. a bunch of high bit characters
>    that will often take 4 (or 5?) characters each to display - have near
>    around 1022 of those - that won't fit on 80x24 screen (4x1022>>80x24) -
>    likewise non-issue with [n]vi
> o [n]vi adds [no]leftright (the complement of vim's [no]wrap) - a
> highly useful
>    thing to add, which classic vi lacks
> o with [n]vi, one can invoke it without a file argument and not set a file,
>    do a :w - and again without filename - and it saves it - yes, to
> temporary
>    file, but if one subsequently crashes out (or system crashes), one can
>    recover from it up to that point.  Classic vi doesn't let you do an
> explicit
>    save to no specified at all file - so recovery is limited to whatever
> point
>    at which classic vi did its last save - it does that semi-frequently, so
>    usually one can recover to within a few or so of the most recent
> changes.
>    Also, when one does such a save with [n]vi, it displays the (temporary)
>    filename to which it saved it ... highly handy, as one can access and
>    use the contents of that file (alas, neither classic vi, nor vim do
> that).
> o classic vi - going to visual mode, it sets the cursor cvvis (if I recall
>    the terminfo settings correctly), and likewise goes to cnorm
>    when going to ex mode, or CLI (e.g. shell out, etc.).  Neither vim nor
>    [n]vi do that - essentially - at least for typical terminals/emulations,
>    that will switch to a block or blinking block cursor for visual mode
> (quite
>    useful - making it much easier to spot where the cursor is - especially
> as
>    one may jump around a lot in vi), and typically an underline or blinking
>    underline for ex/CLI/etc. (non-visual) modes.  One of the very few
> things
>    I miss from classic vi over [n]vi.
> o writing a command out, e.g.:
>    :!some_command<enter or escape>
>    This is one classic vi and vim get right, where [n]vi gets it wrong :-/
>    With classic vi and vim, do command like that, the outputs are just
> written
>    straight to stdout/stderr and/or /dev/tty, etc. as applicable.  After
> which
>    it prompts one (to do another command or return to visual mode).  [n]vi
>    unfortunately gets this one wrong - it buffers and paginates the stuff -
>    similar to less or more - I really don't want anything getting in the
> way
>    between my running the command and its output - unfortunately [n]vi
> inserts
>    itself there in buffering/paginating (window full at a time) the output.
>    Not what I want.  :-/
>
> Anyway, those are the *very* few functional differences between classic vi
> and [n]vi - at least all that I'm aware of.  Classic vi also was rather
> limited in size of file it could handle - but that may have been due to
> typical system/machine resources at the time, rather than classic vi
> itself.
>
> And ... learning vi :-) - I learned it from the VI quick reference card,
> and the vi(1) man page.  Also, by the time (1980) I was using vi, it was
> called and referred to as Vee-Eye, not vI, not visual.  And at least most
> of the documentation I find indicates it's properly pronounced Vee-Eye, not
> vI.
>
> And, ... vi ... is optimized for efficiency of use, not speed/efficiency
> of learning.  So, yes, there is a learning curve to it.  But anyone who
> learns it well, for most text editing tasks (it is a text editor after
> all), will be much faster and more efficient than someone in emacs doing
> comparable typical text editing and a comparably well learned understanding
> of emacs (at least its text editing stuff).
>
>
> _______________________________________________
> conspire mailing list
> conspire at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/conspire
>


-- 

R "Texx" Woodworth
Sysadmin, E-Postmaster, IT Molewhacker
"Face down, 9 edge 1st, roadkill on the information superdata highway..."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/conspire/attachments/20190310/59083844/attachment.html>