Although the days of MS-DOS and its command-line interface have gone the way of the Dodo for the average user, there is still a utility—even a necessity—for the command prompt and command-line programs. Power-users will often rely on such relics, not just because of ingrained training, but because of a certain raw efficiency. This document attempts to rationalize the need for such a tool for anyone who intends to work with modern operating systems beyond the ken of the average user.
90% of the uses of the command line come from the “Quick & Dirty” school of thought, and really comes in one of two flavors: either the programmer of the tool didn’t want to fool around with a GUI (graphical user interface) version—for performance reasons or just plain laziness—or the user of the tool doesn’t want (or need) the pretty face. The other 10% of the time, you’re usually just “stuck” with a tool or application that hasn’t been updated to a GUI version; this percentage will shrink as time goes by and outmoded programs are replaced by newer, GUI versions.
Luckily, we’ve progressed to the point where—in the majority of cases—it really is an option: You the user gets to decide whether or not you want to use the command line. However, if you become more accustomed to a command line, you may find yourself relying on it more and more—I know I do, which is the reason I’m authoring this in the first place! But the first thing you need to understand is the why of the old dragon...
In a modern GUI, the command prompt is typically a throwback or anachronism. It plays a crutial role in older operating systems, as well as modern systems that utilize it as a primary interface (like any flavor of UNIX). Contrary to popular belief, the command line is not the operating system, but is actually a special type of application called a shell. There are both command-line as well as GUI shells; their common property is to present the user with an interface into the operating system. Obviously, the command-line and the GUI shells do them very differently.
An important distinction is necessary here, one that goes beyond the command-line vs. GUI issue: the shell runs on top of the OS, which itself lends a great deal of character to the user interface. I point it out because you can easily have a multitasking OS with a command-line shell (like UNIX), or a single-tasking OS with a GUI shell (like older versions of the Macintosh OS).
Why in the world would someone prefer a command-line shell over a GUI? The primary reason is usually performance. When running a GUI, the machine has to keep track of a great deal more information than with a command line. At the lowest level, the GUI display has a much higher number of discreet items that are tracked: the pixel—or picture element—is the coin of the realm in graphics, while characters are the building blocks in command-lines. The average GUI display will not only have a horizontal and vertical dimensions measured in the hundreds to thousands, but the individual values a single pixel can take on may be several bytes worth of information. The text-based display will typically have less than 100 characters in either dimension; the variety of values that an inividual location is usually not more than a single byte’s magnitude. Just maintaining the GUI display requires a system with upwards of 10 times the processing ability of the command-line system; inversely, the same machine running a command-line shell should have 5 to 10 times more CPU cycles available to run meaningful operations that don’t involve display management.
Another often ignored drain on resources—albeit a potentially small one when coded efficiently—is the pointing device. Although it’s possible to use a mouse (or other pointing device) with text-based utilities, it is the GUI that typically makes it mandatory. Aside from the need of the shell to keep track of the location of the pointer at all times, applications typically are called on to respond to mere movements of the pointer, which may or may not be relevant to the operation at hand. Another annoyance with the pointing device is the full dependence on it: many applications that don’t logically require a pointing device (like a word processing or spreadsheet program) often leave the user no option when invoking certain parts of a GUI application: there is no way to accomplish an arbitrary activity with only the keyboard. Time and efficiency are sacrificed when the user must move his hand to the pointing device, locate the pointer on screen, move the pointer to the display positions necessary to invoke specific responses, and invoke those actions through (typically) several clicks and/or drags. User time and efficiency should also be considered part and parcel of system resources!
Above, I indicate several advantages to the command line shell in comparison to the GUI. However, it’s certainly not the environment I would want to use for day-to-day work. The GUI allows the user to see output formatting more readily (WYSIWYG), and on a multi-tasking OS, permits several simultaneous applications to display side-by-side on a large monitor. In fact, text-based shells have been developed with this capability (DesqView is a notable example for the PC), but these are more kin to the GUI than the command line because of their menued, point-and-click interface elements. Years of research into UI design indicate that the GUI is the best way to present the information to a user. Most modern OSes have a GUI shell, and they’re the easiest way to learn a system. Personally, I can’t stand working on a non-GUI shell for too long; so why would I extol the command line??? Simply put: I get the best of both worlds by running a command-line shell as a separate application under a GUI shell.
It comes down to this: Some activities are easier and/or faster to perform from the GUI, while others are better performed at the command line. Using an unfamiliar program is almost always easier with a well-designed GUI interface, with activities and options flowing into the normal work path. Common, repetitive tasks, however, can be easier and/or more efficient to perform at the command line: the shell itself may natively support operations that can be managed or accommodated with only a few simple keystrokes. Further, the shell may support a form of automation (the batch language) that shortens even the most tedious repetitions to a single command.
If you don’t buy my arguments for using the command shell in addition to using a GUI, it’s time to drop the other shoe (metaphorically speaking, naturally): If your career intentions ever intersect the computer world in such a way that the computer itself becomes more than “just a tool” that someone else will maintain and administer, you’ll need to be familiar with the command line. Some systems you’ll encounter may be so antiquated or specialized that you’ll have no choice: configuring a router usually requires a terminal console and lots of command-line savvy. Other systems may have one or two quirks that require a command-line utility to fix it or perform specialized operations with it. On most GUI systems, the command line will let you see its hidden underbelly, a bonus when you have to troubleshoot problems with its default GUI shell! Still other systems emphasize performance to such a high degree that wasting CPU cycles on a GUI shell is unthinkable.
If that’s the direction you are headed in, then force yourself to become familiar with the command shell and all its arcane usages.
If your primary systems are PCs, and you just need a good primer on the DOS command line, try one of the following links for more information on usage and enhancements:
| Comments? Email jim3@millard.org | Last updated October 20, 2001 |