In this article, 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 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 (to which I believe the E.i.C. of this site has ported a number of programs) 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, since the source for the vast majority (all?) of its core programs is available through BSD).
- Although today's hardware largely renders 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.
- 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. Framebuffers 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.
I think I have made a case for the continued existence of the command-line interface. I hope there will be a place for the little blinking cursor (in a window, all right) in whatever fancy new desktop wins the wars.
A note: I do not necessarily consider "user-friendliness" to be a necessarily valid argument. In '91 an office worker whose computer ran Unix was expected to know things like troff, and it was perfectly natural--the company determined what was friendly for him. "Joe User", like a normal Russian worker, is too often something completely fictional. Remember that switching from familiar DOS to unfamiliar Windows was also hard for many.
About the Author:
Greg Afinogenov splits his time between America and Russia. Computers for him are a hobby--his main study is history.