terse editor

[jc at trillian.mit.edu (John Chambers)]

David Kramer wrote:
| dsr at tao.merseine.nu wrote, On 02/11/2005 07:57 PM:
| >
| > The big split, in my experience, is actually between system
| > administrators, who expect to find vi on every system, always
| > working exactly the same way, and programmers, who carry around
| > a complex customized emacs environment that suits their every
| > whim.
|
| Yup.  Back in the bad old days of DOS, admins needed to know edlin, because
| that's what you absolutely know was installed on each computer.  It was like
| doing a term paper in sed, but that's what you had to do.  Likewise, it
| behooves all admins today to at least know vi, whichever their preference.

One thing I've  often  been  glad  I  did  was  to  learn  the  whole
ed/sed/ex/vi  suite  of editors (which are closely-related programs).
The reason is "admin" tasks, where you often find yourself trying  to
diagnose  problems on a machine that's in some sort of damaged state.
Or you're connecting remotely and find that the connection is  barely
sane (or has some sort of "intelligent' code that does something like
eating control characters ;-).

Sophisticated editors  (sometimes  including  vi)  often  can't  work
sensibly in such cases.  All ed needs is a dumb terminal to work. The
ex editor is actually a mode within vi, accessed via a  'Q'  command.
It's  actually vi but without any full-screen capability, so it works
in some cases where vi doesn't. With vi, you need a terminal that can
do  full-screen operations sensibly, and you need to guess a value of
$TERM that will work, but 'ansi' or 'vt100' usually works.

In any case, I've often used ed or ex or vi to explore  brain-damaged
systems and get them working again, in conditions where other editors
simply couldn't be used.

The ed/sed parts of this package also have the  advantage  that  they
can  be called from scripts, with no terminal at all.  They just read
stdin and write stdout as streams.  I've done a lot less of  this  in
the past 10 years, since perl is often a better tool.  But still, for
simple munging of files or data streams, they are very useful  tools.
I have a number of sh scripts that contain code like:

if ...
then ed $file <<EOF
... ed commands ...
w
q
EOF

If you know enough of ed to do this, then you know enough to  use  it
interactively  as  an  admin tool to explore and fix damaged systems.
And the ed commands all work in vi, in the form of the ':'  commands.
When  you're  faced with a machine across town or half-way around the
world that's in trouble, and something in the telnet or ssh  link  is
making full-screen editors unusable, this can be really valuable.  If
the connection is less flakey, I've seen a  lot  of  cases  where  vi
works but fancier editors like emacs don't.

OTOH, if you want an editor that does everything, is both a  full  OS
and a programming language, and comes with a complete geek subculture
of its own, I'd highly recommend emacs.