<div dir="ltr">The Berkeley enhancements (Visual, csh and a number of other things) were originally under /usr/ucb/bin<div><br></div><div>Michael is correct about vi being built on top of ex correctly.</div><div>For years the dot file for vi was actually .exrc</div><div>I do remember the command being "visual" and updating my "cashrocks" file (.cshrc) "aliases" section.</div><div>Im trying to remember whether this was Unix v6 or v7.</div><div><br></div><div>I believe the code to Bills original vi was ALWAYS opensource as it was developed on the university machines, </div><div>as was the original ingres db and a number of other things.</div><div><br></div><div>If I were to search for Bills original code, I would look in the BSD archives rather than the LINUX.</div><div>By the time RedHat shipped in shrink wrap, I think the rewrite of Bills code had already bun if not completed.</div><div><br></div><div>I know that with VIM uses a .vimrc file. I dont know if "non vim vi" still uses .exrc or what.</div><div>I never needed to mess with it, so I never checked.</div><div><br></div><div>I still had the vi alias in my dot files in v7.</div><div>I *THINK* it was BSD Tahoe when they just renamed visual to vi.</div><div><br></div><div>For those who dont know, this was Bill Joy, one co founder of "Stanford University Networks" AKA: Sun Micro.</div><div><br></div><div><div>I note that after Unix v7, ATT started getting VERY interested in backtracking to v6 with the BSD stuff removed </div><div>and then going down the parallel tracks of Sys3 & sys5.</div><div>My personal suspiction was that ATT was afraid the universities were rujnning away with THEIR product and therefore</div><div>retreated to v6 without the BSD enhancements and built on those.</div><div><br></div><div>Interestingly enough, 2 competing projects at ATT gave us Sys3 & sys5. One did not evolve into the other.</div><div>I was supporting v7, BSD, S3 & S5 and had a hell of a time keeping them straight.</div><div><br></div><div>Interestingly enough, the ATT "system" paths both DID include vi, but many of the other BSD enhancements were not.</div><div>One of the things that drove me mad was that dump & restore were originally removed from Sys3 & Sys5.</div><div>ATT told us that we should be doing backups with either dd or cpio.</div><div>ATT eventually caved in both S3 & S5 and dump & restore returned.</div><div>Finally S3 died and the S5 I was dealing with the most was Sunos-5 (AKA Solaris2).</div><div>There was a Solaris 1 (Sunos4.1.4) but thats immaterial to the story.</div><div>By Solaris 2.4 (SunOs5.4) it was finally something that I could stand and by Solaris 2.5 I actually liked it.</div><div><br></div><div>Starting with Solari7 7, they droped the two point but Solaris 7 was still SunOs5.7.</div><div>They decided that the product looked more mature growing in full numbers rather than decimals.</div><div>In Solaris 8, it was still .exrc</div><div><br></div></div></div><div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br>
<a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 10, 2019 at 1:50 PM Michael Paoli <<a href="mailto:Michael.Paoli@cal.berkeley.edu">Michael.Paoli@cal.berkeley.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> From: Texx <<a href="mailto:texxgadget@gmail.com" target="_blank">texxgadget@gmail.com</a>><br>
> Subject: Re: [conspire] Technical Interview Performance by <br>
> Editor/OS/Language - Triplebyte Blog<br>
> Date: Sat, 9 Mar 2019 15:15:26 -0800<br>
<br>
> I learned visual (the REAL name for vi) from man vi.<br>
> The name vi came from the alias students were setting in their dot files.<br>
> Emacs is a better option than Microsoft but could use a better editor.<br>
<br>
"Real name" might depend on the "when". I know little of vi - at least<br>
by any personal experience, before 1980. By the time (1980) I was using<br>
vi, it was already well established on Unix in University of<br>
California environments (and likely some bit beyond?). The command was<br>
vi (not visual - though visual may have remained as an additional hard<br>
link?), man page was vi(1), it was of course also a hard link to ex.<br>
As I recall (and I think various documents support), first - at least<br>
on Unix, there was ed, then ex, then visual mode was added to ex,<br>
from ex one would enter visual mode by typing:<br>
visual<br>
(and it still works that way)<br>
which could also be shortened to shortest unique abbreviation thereof:<br>
vi<br>
(but not v, as that's another command in ex/vi - the complement of g).<br>
vi[sual] mode in ex became so popular, that code was modified such<br>
that if it was invoked with arg0 being vi (and/or visual?), it would<br>
start in visual mode, and the hard link(s) for vi (and visual?) were<br>
added - so one could invoke it into visual mode from CLI by simply typing:<br>
vi [options and/or arguments, etc.]<br>
$ (cd /usr/bin && ls -onLid vi ex)<br>
311624 -rwxr-xr-x 3 0 472216 Dec 30 2016 ex<br>
311624 -rwxr-xr-x 3 0 472216 Dec 30 2016 vi<br>
$<br>
<br>
> I am not aware of any vi package with Bills original code.<br>
> It appears to have been completely rewritten in several versions including<br>
> vim and nvi.<br>
><br>
> I don't know the current bad port tree well, so it might still be there,<br>
> but none of Bills code remains in either Deb or RPM trees that I can find.<br>
<br>
Some year(s) back ... not all that horribly long ago, ye olde classic<br>
vi became open sourced - I think most useful search term may be<br>
"classic vi". I don't know that any linux distros (or BSD) have<br>
packaged it - but the source code should be out there ... *somewhere*.<br>
Also, not sure what license it was released under.<br>
Anyway, by the time classic vi was open sourced, vim and [n]vi (not to<br>
mention other clones) had long gone well beyond classic vi.<br>
About the last place I saw classic vi, was Solaris ... I think 10 (or maybe<br>
9) ... before Solaris dropped classic vi and switched to vim.<br>
The BSD folks (or mostly from BSD) had by then already done a<br>
reimplementation of vi ... on BSD systems it *is* vi, ... just not<br>
"classic vi". Beyond BSD it's often/typically nvi, but can also be<br>
configured to be or be installed as vi (at least for most linux distributions<br>
that bother to have it available at all).<br>
The design goals of [n]vi were essentially a feature-for-feature,<br>
bug-for-bug reimplementation of vi (with of course source code not being<br>
so encumbered to conflict with release under, e.g. BSD, or similar licensing).<br>
So, [n]vi is *very* close to classic vi in functionality. Anyone who's<br>
fingers/brain are used to flying through classic vi with great efficiency<br>
and speed, will be highly at home on [n]vi ... not so with vim.<br>
The number of functional differences between [n]vi and classic vi are<br>
*very* small and minimalistic ... would rather expect that from<br>
the BSD folks :-) ... they also avoid lots of bloat in, e.g. tar, cpio,<br>
pax, ... whole lot 'o cruft/bloat they just don't add. That's often<br>
a very good thing. [n]vi is even much smaller that vim.tiny - which weighs<br>
in at about twice the size/bloat of [n]vi. Let's see ...<br>
$ ls -on /usr/bin/vi /etc/alternatives/vi /usr/bin/nvi /usr/bin/vim <br>
/etc/alternatives/vim /usr/bin/vim.basic /usr/bin/vim.tiny<br>
lrwxrwxrwx 1 0 12 Jan 7 2013 /etc/alternatives/vi -> /usr/bin/nvi<br>
lrwxrwxrwx 1 0 18 Jan 7 2013 /etc/alternatives/vim -> <br>
/usr/bin/vim.basic<br>
-rwxr-xr-x 3 0 472216 Dec 30 2016 /usr/bin/nvi<br>
lrwxrwxrwx 1 0 20 Jan 7 2013 /usr/bin/vi -> /etc/alternatives/vi<br>
lrwxrwxrwx 1 0 21 Jan 7 2013 /usr/bin/vim -> /etc/alternatives/vim<br>
-rwxr-xr-x 1 0 2413032 Sep 30 2017 /usr/bin/vim.basic<br>
-rwxr-xr-x 1 0 1062744 Sep 30 2017 /usr/bin/vim.tiny<br>
$ echo $(lsb_release -d) $(uname -m)<br>
Description: Debian GNU/Linux 9.8 (stretch) x86_64<br>
$ ls -on /usr/bin/emacs /etc/alternatives/emacs /usr/bin/emacs24-x<br>
lrwxrwxrwx 1 0 18 Nov 5 2015 /etc/alternatives/emacs -> <br>
/usr/bin/emacs24-x<br>
lrwxrwxrwx 1 0 23 Jan 18 2013 /usr/bin/emacs -> /etc/alternatives/emacs<br>
-rwxr-xr-x 1 0 15759624 Sep 11 2017 /usr/bin/emacs24-x<br>
$<br>
What (very slight) functional differences between classic vi and [n]vi?<br>
In all my years using classic vi, and [n]vi, I think these are all that<br>
I've noticed:<br>
o line length limit of 1022 characters in classic vi (written in C,<br>
presumably 1024 byte array, 1022 characters text max + newline +<br>
terminating null for C string = 1024 characters - no such limit<br>
in [n]vi<br>
o classic vi craps out (drops to ex mode? Or I think it more just dies<br>
some type of death and exits) - if one ever has a display line that<br>
can't fit on the total window size - e.g. a bunch of high bit characters<br>
that will often take 4 (or 5?) characters each to display - have near<br>
around 1022 of those - that won't fit on 80x24 screen (4x1022>>80x24) -<br>
likewise non-issue with [n]vi<br>
o [n]vi adds [no]leftright (the complement of vim's [no]wrap) - a <br>
highly useful<br>
thing to add, which classic vi lacks<br>
o with [n]vi, one can invoke it without a file argument and not set a file,<br>
do a :w - and again without filename - and it saves it - yes, to temporary<br>
file, but if one subsequently crashes out (or system crashes), one can<br>
recover from it up to that point. Classic vi doesn't let you do an explicit<br>
save to no specified at all file - so recovery is limited to whatever point<br>
at which classic vi did its last save - it does that semi-frequently, so<br>
usually one can recover to within a few or so of the most recent changes.<br>
Also, when one does such a save with [n]vi, it displays the (temporary)<br>
filename to which it saved it ... highly handy, as one can access and<br>
use the contents of that file (alas, neither classic vi, nor vim do that).<br>
o classic vi - going to visual mode, it sets the cursor cvvis (if I recall<br>
the terminfo settings correctly), and likewise goes to cnorm<br>
when going to ex mode, or CLI (e.g. shell out, etc.). Neither vim nor<br>
[n]vi do that - essentially - at least for typical terminals/emulations,<br>
that will switch to a block or blinking block cursor for visual mode (quite<br>
useful - making it much easier to spot where the cursor is - especially as<br>
one may jump around a lot in vi), and typically an underline or blinking<br>
underline for ex/CLI/etc. (non-visual) modes. One of the very few things<br>
I miss from classic vi over [n]vi.<br>
o writing a command out, e.g.:<br>
:!some_command<enter or escape><br>
This is one classic vi and vim get right, where [n]vi gets it wrong :-/<br>
With classic vi and vim, do command like that, the outputs are just written<br>
straight to stdout/stderr and/or /dev/tty, etc. as applicable. After which<br>
it prompts one (to do another command or return to visual mode). [n]vi<br>
unfortunately gets this one wrong - it buffers and paginates the stuff -<br>
similar to less or more - I really don't want anything getting in the way<br>
between my running the command and its output - unfortunately [n]vi inserts<br>
itself there in buffering/paginating (window full at a time) the output.<br>
Not what I want. :-/<br>
<br>
Anyway, those are the *very* few functional differences between classic vi<br>
and [n]vi - at least all that I'm aware of. Classic vi also was rather<br>
limited in size of file it could handle - but that may have been due to<br>
typical system/machine resources at the time, rather than classic vi itself.<br>
<br>
And ... learning vi :-) - I learned it from the VI quick reference card,<br>
and the vi(1) man page. Also, by the time (1980) I was using vi, it was<br>
called and referred to as Vee-Eye, not vI, not visual. And at least most<br>
of the documentation I find indicates it's properly pronounced Vee-Eye, not<br>
vI.<br>
<br>
And, ... vi ... is optimized for efficiency of use, not speed/efficiency<br>
of learning. So, yes, there is a learning curve to it. But anyone who<br>
learns it well, for most text editing tasks (it is a text editor after<br>
all), will be much faster and more efficient than someone in emacs doing<br>
comparable typical text editing and a comparably well learned understanding<br>
of emacs (at least its text editing stuff).<br>
<br>
<br>
_______________________________________________<br>
conspire mailing list<br>
<a href="mailto:conspire@linuxmafia.com" target="_blank">conspire@linuxmafia.com</a><br>
<a href="http://linuxmafia.com/mailman/listinfo/conspire" rel="noreferrer" target="_blank">http://linuxmafia.com/mailman/listinfo/conspire</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><br>R "Texx" Woodworth<br>Sysadmin, E-Postmaster, IT Molewhacker<br>"Face down, 9 edge 1st, roadkill on the information superdata highway..."<br></div><div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br>
<table style="border-top:1px solid #d3d4de">
<tr>
<td style="width:55px;padding-top:13px"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;"></a></td>
<td style="width:470px;padding-top:12px;color:#41424e;font-size:13px;font-family:Arial,Helvetica,sans-serif;line-height:18px">Virus-free. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link" target="_blank" style="color:#4453ea">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div>