[TriLUG] vi(m) #1 of the top ten linux tools admins should know/have

[Aaron S. Joyner]

jonc wrote:

>...
>It's surprising to an old Unix hound like myself that so much of the
>newer Linux converts don't know vi. I guess that's really a good thing.
>Most distros are now easy to manage using GUIs; folks can strive and
>survive without the command-line if they must.
>  
>
Let me preface this by saying that someone who wants to use Linux on the 
desktop (my wife for example), wouldn't want to, and shouldn't 
necessarily need to, deal with the command line or either of the 
powerful editors under discussion, with any frequency.  The modern GUI 
desktop is what made desktop computing usable and comprehensible for the 
average Joe (or Jane).  But this thread (and this mailing list) isn't 
primarily about (or read by) the average Joe (or Jane), and that's where 
the point Jon makes above breaks down.

Any power user, or a SysAdmin or Developer (aka professional user of 
*NIX), who lives their life mostly in the GUI, is missing the point.  
Let me clarify that living in X windows and using your mouse to point at 
Xterms (or Eterms) does not count as "living life mostly in the GUI".  
The real strength of the UNIX design, from it's very inception on 
through the modern Unicies, is small programs, which do one task, and do 
it well, connected by clean, clear and simple text-based interfaces.  
Being able to chain these tools together for amazing and off-the-cuff 
solutions to surprisingly complex problems, which the authors of those 
programs probably never considered, is *exactly* what makes UNIX a 
powerful platform.  The thing that the original article missed, the true 
killer app of the UNIX world, is the shell.  It's the silent glue which 
very few people think about, which holds everything together.  You can 
put the religious arguments about shells (and even more popular, 
editors) aside, the details don't matter.  It's the fundamental design 
that allows you to string together text-based programs with pipes and 
simple conditions and loops that make good UNIX admins orders of 
magnitude more efficient than even good Windows admins (or admins most 
other platforms, of which there are hardly any left, for that matter).

So on the religious argument of editors, let me just say that I have 
nearly daily arguments with my Emacs-using office mate about the virtues 
of vim*.  :)  This doesn't obviate the fact that every time we touch a 
file on a server the edits are done with vi (yes, vi, vim's not 
available**), and both of us are reasonably fluent in vi.  It's 
something that any sys admin really must know, and for the sake of 
efficiency should know really well (as Jon mentioned, doing something 
like complicated search and replace or sorts or other advanced edits in 
nano would be... unbearably tedious).  I firmly believe that it's much 
more efficient to primarily learn one editing style, and know everything 
there is to know about it, and know just enough to get around in the 
other.  This way you can be as efficient as possible with what ever your 
daily editor of choice is, which should be priority number one.  You can 
make the argument either way, that it's better to learn Emacs and know 
enough to get around in vi, or learn everything there is to know about 
Vim/vi and know enough Emacs key bindings to make efficient use of 
programs that use them (ala the ^-a, ^-e, ^-k, etc which are so common 
in bash, most irc clients, etc).  I generally find that classically 
trained programers, people who come from a CS background, tend to favour 
IDE-style features, such as are provided more readily by Emacs.  Vi/vim 
tends to be favoured by those who come from more humble backgrounds in 
the Admin world, primarily debugging simple code or using languages (ala 
Perl, Bash) which don't lend themselves to IDEs for one architectural 
reason or another (or amusingly, by those people who have been doing it 
longer than IDEs have been popular).  I don't find the needs to be able 
to right-click on a function and be able to go to it's definition, and 
if I really need that kind of power I can do it with ctags in vim, but 
it's not something that I really use on a daily basis.

For those who might suggest that some classically styled pico-esque, 
notepad-esque or M$ Word style editor might possibly be a comparable 
choice to vim or Emacs has clearly never mastered either editor, and 
probably never even stood over the sholder of someone who's really good 
with either.  Until you've seen it, or experienced it, it's hard to 
believe how much more keystroke- and time-efficient you can be with a 
really powerful editor.  I highly recommend that everyone should learn 
one (and that one should be vim, of course). *wink*

Aaron S. Joyner


* - This debate usually crops up in the brief interludes when we're not 
busilly trash-talking the other's preference of scripting language, 
Python or Perl, depending on who's doing the trashing.  :)
** - Well, technically, almost any time you run vi these days it's vim 
(busybox being the only likely exception).  In most cases, you can call 
up the vim feature set by running ":set nocp", if not, it's because it 
was compiled w/o the vim feature-set, usually for space, but this is 
relatively unusual.

PS - A couple other random musings on vi vs. vim.  Everyone should start 
with vi, if just for a few days, to really get a feeling for what works 
and what doesn't in vi.  And it helps if once you get used to vim, you 
turn off the vim feature-set for a while (:set compatible), in the 
interest of enforcing those differences to yourself.  Every time you 
reach for something in vim that doesn't work in vi, such as block 
highlighting, find a way to do it with just what vi  provides.  
:.,.+10s/foo/bar/ will do search and replace over the next 10 lines 
only, or :%s/foo/bar will do the same for the whole file, for example.  
The first of these two operations is easier in vim by block 
highlighting, but knowing how to do selection brings home that it's 
faster and easier to do global search an replace the later way, than 
something like gg^VG:s/foo/bar in vim.  As continous learning, try to 
frequently look for vim cheat sheets or hints on the web to find new 
tricks to make yourself easier / faster.  You'll find that your brain 
can only handle so many new features at a time, and it'll take a while 
for new things to sink in.  Go back and look at that same info on the 
web every few weeks or months as you're learning, and every time you'll 
probably find something new will make it's way into your daily use.  
I've been learning vi and vim for over a deacade now, and I still find 
myself learning new tricks in exactly this same way.  The ideal scenario 
is to watch someone else work for a while, especially someone more 
experienced than yourself; they're bound to do something a little 
different, and those experiences tend to make the tips and tricks sink 
in better than just reading them does.  Having that same or another 
person watch you work and offer tips is often equally insightful.