It is not fashionable nowadays to speak of the merits of the command
line,
in an age where things like streaming video and Aqua are an integral part of
our daily life. However, I do not think that typed-in commands must necessarily
be
consigned to the dustbin of computer history. Of course, I am not
suggesting that we all drop X and Windows and pretend like we are living in
the early eighties. The command line interface still has much to offer us,
and many of its benefits simply cannot physically be emulated or even replaced by
graphical
ones.
In this writeup, I will be analyzing the specific properties that make the
command line unique and irreplaceable. I will likewise analyze the graphical
UI's features--though only giving it a cursory look, since I assume my audience
does not need to be persuaded to make the most of its video hardware. I will
programs and libraries (Unix's command line has largely abandoned that conflict,
was expected to
know things like troff, and it was perfectly natural--the company be looking at the Unix shell,
since it is the most full-featured and powerful of
such interfaces (DOS, of course, had very few features worth talking about; it
must be given its due, though--it brought millions of people into computing). I
will be looking at GUIs on a more general level.
Benefits of the CLI:
The structure of Unix and of its shells allows powerful mechanisms of piping
and redirection to work. Anyone who has even done administration tasks in this
environment, even simply on a desktop machine, knows that things like sed and
sort are a necessity. What makes this unique is that it is universal--there is
no command whose output cannot be redirected somewhere else, whether to a file
or to another command. It is conceivable for a programmer to, say, add an "Edit
this output in Notepad" option to a number crunching program. But to make an
entire graphical userspace have universal interfaces for redirecting output is
truly a titanic task (KDE and Kparts have made good progress, but as we all
know, the free Unix GUI is badly fragmented, making universality practically
impossible). A good part of the difficulty of doing this comes from the
heterogenity of the data being operated upon, as well as the inherent
multifunctionality of graphical interfaces--although cut and paste is a good
thing too.
The world of the Unix console, as opposed to its desktop, is rather
unfragmented. POSIX, that mighty juggernaut of standardization, has ensured
that porting command-line programs from one Unix to another is a relative
breeze. Especially remarkable is the fact that it can also function for wholly
un-Unix systems--like the BeOS or QNX, or even Windows, all of which have rather
complete suites of GNU programs (in the latter case, two). Porting a program
that uses graphics, however, is sometimes difficult even among
Unices--especially given the varying degrees of freeness of graphical Unix
programs and libraries (Unix's command line has largely abandoned that conflict,
was expected to
know things like troff, and it was perfectly natural--the company since the source for the vast
majority (all?) of its core programs is available
through BSD).
Although today's hardware largely renders ( wah-wah-waaah
) this point moot, command-line
programs incur much less size and speed overhead than their graphical
counterparts. In fact, bash itself, at 600-odd kilobytes, is likely to be one
of the largest command line programs one runs. By "overhead" I mean exactly
that--the amount of resources consumed that is not strictly necessary to the
task at hand. So, for instance, it stands to reason that GCC will soak up more
memory and CPU than KMenuEd, but that is inherent in its function. Also, when
one recycles old hardware for routers and minor servers, it would be a waste to
put a graphical desktop on it. This is one of the main reasons that Linux (*BSD
too) is popular for reincarnating 486s--it can be easily administered via
command line.
Remote access is a necessary element of such administration. There is, of
course, VNC and PCAnywhere and what-have-you, but of those, only VNC is as
cross-platform and simple as SSH. An SSH session essentially can start from
anywhere, since there are clients available for a huge number of platforms.
Also, the OpenSSH folks are serious about security: encryption allows one not to
worry about passwords. VNC, though, unless tunnelled through SSH, offers no
security at all. Textual information is also much smaller than graphical,
obviously making remote connections less of a pain in the neck. It is extremely
difficult to get a tolerable speed with VNC, whereas with SSH the speed is near
local. The last element is antiquated, but nevertheless powerful--serial
consoles. There simpty is no better tool to administer a temporarily offline
headless server.
These are some of the virtues of the command line. There are other things
specific to shells that make life much easier, but these are the important ones.
Benefits of the GUI:
An important benefit is the display of dynamically modifiable abstract
information (Short example: Open a file manager and delete a file, then make
sure it is deleted: three shell commands vs. a mouse click.). This means web
browsing, spreadsheets, word processors, etc. are possible. This is available
for the console with Curses and Turbopower and that sort of thing, but I do not
think that these libraries belong to the CLI proper. They form a sort of middle level between the
two.
Of course, aesthetics. It is much more pleasant looking at Luna than at a
serial console (I think the Luna widgets are the coolest thing since GEM, but
that's just me), and I think a good reason for the migration to GUI is the
prettier and more natural feel. It is no accident that Unix started recovering
from its slump when high-quality desktop environments (GNOME, KDE, not CDE)
became available--because of Linux.
Modern computing is very much focused on media, and that is naturally only done
with graphical environments. Framebuffer consoles are inadequate for this kind of
function.
The graphical desktop allows true multitasking (for the user) to take place.
Switching virtual terminals is a poor replacement for switching windows, because
windows allow more than one program to show its output at the same time,
resulting in much increased efficiency and flexibility.
A note: I do not necessarily consider "user-friendliness" to be a necessarily
valid argument. In '91 an office worker whose computer ran Unix (or was a terminal) was expected
to
know things like troff, and it was perfectly natural--the company determined
what was friendly for him. "Joe User", like the "Worker" of the Communists, is
too often something completely fictional.
Remember that switching from familiar DOS to unfamiliar Windows was also hard
for many.
Author's note: This text was originally posted on OSNews on September
3, 2003. It was written by me. Thus, it infringes on no
copyrights.