It was relatively common in the 1990s to hear that the command line's days were numbered. Both claims of its obsolescence and rumors of its impending demise were greatly exaggerated.
Some people fear the command line. Others consider it arcane and obsolete. Many of us know the truth, though; often, command line tools are just the right tools for the job.
Command line utilities and applications provide us with many benefits that are unavailable, difficult to achieve, or incomplete with any GUI applications. These benefits are numerous, but five in particular may come immediately to mind:
Anyone who does paranoid cookie management in Firefox long enough is likely to run into the 1001 Cookies problem, where cookie management dialog windows appear so quickly and in such numbers that it seems like it might take all day to get through them all. This example demonstrates a problem of GUIs and other captive interfaces: scalability. When only performing a single, simple task once, it may seem quite easy to just click on a couple of interface buttons and move on. When there is suddenly a glut of such tasks, and they all require the user's attention (such as choosing which cookies to accept and how long to keep them), the GUI becomes more of a hindrance than a help, and your taskbar (if you use one) quickly fills up with window buttons that show something like "C..." and nothing else.
By contrast, command line tools tend to offer far greater opportunity for handling such scalability problems quickly and easily. Organizing output into groups, so tasks that require the same user response are all lumped together, allows a single action to be taken to achieve results over large numbers of discrete tasks. Where those legions of Firefox dialogs require a decision and click-to-execute for each one individually, a little judicious sorting and piping the output of different invocations of the yes command can offer the command line tool user the ability to use only a handful of steps to deal with hundreds of discrete tasks.
Any Unix sysadmin should understand the power of scripting for command line tools. Many Microsoft Windows administrators, however, are not as familiar with the power and flexibility of the command line to the same extent as their Unix sysadmin brethren. The reason for this is that, when it comes to system administration, MS Windows administrators often have a much harder row to hoe due to the mediation between the administrator and the system's basic functionality that is forced on them by the GUI-centric design of the operating system. When there are five buttons that need to be clicked in a particular order eighteen times a day in a GUI application, one has to click those buttons eighteen times, but when a particular complex command needs to be entered eighteen times in a Unix shell, it is a trivial exercise to script that activity to remove some of the administrative overhead burden for the sysadmin.
The competent Unix sysadmin is the Maytag repairman of the information technology world. Automation through system scripting pares away all the tedium and repetitiveness of their daily tasks until they have nothing left to do aside from being available in case something breaks and -- if they are lucky enough to have bosses who allow that sort of thing -- come up with ideas for how to improve on the way things are done. Meanwhile, the GUI-only administrator is often run ragged every day doing things by hand (using a mouse) that the competent Unix sysadmin has delegated to admin scripts long ago.
The best MS Windows administrators do what they can to offload their own repetitive tasks to admin scripts as well, of course, but the relative weakness of the system administrator's automation options serves as a limiting factor. To a nontrivial degree, the difference is the pervasive influence of the command line functionality of Unix, contrasted with the very GUI-centric design of Microsoft Windows. Where GUI developers do plan for the ability to automate activities, they generally have to build macro systems into each and every application separately, whereas the command line itself is the "macro system" for every command line utility available, ensuring uniformity of scripting interfaces and the availability of automation capabilities for many more pieces of software than would otherwise be so easily scriptable.
3. Simple design
The benefits of a simple design are well-known. For instance, it seems reasonable to say that simplicity is security. In case that explanation is not persuasive, you can read about how design simplicity is an important element of open source security, including the unavoidable probability that more code means more bugs. More specifically, when considering the security benefits of simple design, it is important to understand the relationships between security, complexity, and the GUI environment.
Command line tools often benefit from more straightforward, obvious, simple designs. Part of the reason for this is the fact that command line tools are easily written as smaller, simpler tools that -- in the Unix tradition -- each do one thing well. Where captive interfaces are The Way To Do It with GUI applications, forcing developers into a creeping featurism mode when "improving" their software to allow users to accomplish more complex tasks, command line utilities that each Do One Thing Well can be tied together on the fly by the Unix pipeline to accomplish complex tasks without requiring anyone to add features to the cat utility itself such as:
- features for "reading level" estimation
- PDF export
- spell and grammar checking
4. Simple interface
GUI applications rely on menus and buttons to get anything done. This means that powerful tools require complicated interfaces so that the user can access (almost) all the features of the application with a mouse. The more features an application has, the more complicated the interface gets. The Microsoft Office productivity suite is a prime example of the kind of complexity the interface takes on when many features are added. That application suite has gotten so complicated over the years that the people at Microsoft eventually had to come up with an innovative approach to managing that complexity. The result was the Ribbon -- a sort of dynamic menu bar, where your application tries to present the most-used and most useful features at any given time depending on what exactly the user is doing at that moment. This approach is interesting and does help manage the complexity of the application suite, but at the same time it supports casual users' most common activities at the expense of making things much more difficult for "power users" and their productivity. The most knowledgeable users tend to have the most trouble with the Ribbon.
Command line applications and keyboard-driven, console based, captive interfaces can offer simple interaction for casual users without pulling out the rug from under the feet of more knowledgeable users. Many such tools will provide simple usage information by using a --help option when invoking it at the shell, or easy access to usage help from within a captive interface via a keystroke or two. Beginners can learn the rudimentary basics easily, and as they learn more about how to use it their facility with the application expands. The simplicity of the interface never comes at the expense of that expanding knowledge.
5. Stable design
As GUI environments evolve over time, acquiring new bells and whistles and feature sets, GUI applications need to change to fit into those environments. As GUI applications become more complex over time with the addition of new features, the applications undergo mutation so that they never quite work the same as they did a version ago. Backward compatibility is a very difficult achievement with new versions of GUI applications for these reasons and more. As a result, users need to relearn how their favorite GUI applications work to some degree every time they upgrade. Even if they never have any use for new features added to the applications, the old features they use regularly are often changed with the release of new versions. Usually, they do need new features, if only a few, but the learning curve for changes in how the old features are used is usually much steeper than that of a small handful of new features they will use in the future.
In addition, the simple fact that users have been doing the same things the same ways for quite a while can result in what educators call "negative transference of learning", where what they already know (in this case from an earlier version of an application) interferes with their ability to learn new knowledge in similar circumstances. Command line utilities, especially given their typically simpler designs, do not tend to suffer this problem to nearly the same degree. If a new feature must be added, it usually does not require reshuffling the old features, which can almost always be easily accessed the same way they were accessed before the upgrade.
Given the greater facility for tying separate tools together at the command line than in the GUI environment, adding new features to a particular tool is often unnecessary (and undesirable) anyway, because new functionality may simply be built as a new tool, allowing the user to employ those two tools together via the Unix pipeline. The end result is that the end user typically does not have to worry about unstable software design where interfaces and back ends behave in unexpected new ways when a new version of the utility is released.
The importance of options
Of course, the command line is not suitable for everything. GUIs and other captive interfaces do provide benefits that are absent, or difficult to achieve, solely with command line utilities. There are some tasks, in fact, for which substantial expertise is necessary to even encounter the benefits of a command line approach, so that any inexpert user will only be hindered by the lack of a captive interface.
For most cases, even when a captive interface is appropriate, command line tools are also important to have. In fact, in many cases, if a captive interface is a good idea it should be built on top of command line utilities, such that the captive interface itself -- whether a GUI or a console-based interface such as that provided by the curses library on Unix -- is only a thin veneer over utilities that can also be invoked individually from the command line or in a script when needed.
There is little chance that the GUI will be neglected in favor of the command line in day to day end-user computer software design. Many developers, however, seem content to ignore the importance of the command line and the benefits it can provide for users. Part of the reason for this is that the users themselves are often not aware of the benefits that can be had by using command line tools. If you are one of those users, it may be time to pick up a copy of the best Linux book available and familiarize yourself a bit more with the benefits of command line tools.