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.
--
TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
