Operating systems

Five benefits of command line tools

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:

1. Scalability

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.

2. Scriptability

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.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

18 comments
raimo.koski
raimo.koski

From a doc I recently wrote: "The command line interface, especially in Linux, is the most powerful user interface. Using that power requires knowledge. You have to know the words and the syntax and there are many languages or interpreters available, many specifically designed for certain types of tasks and many generic languages and some, like the shells, acting as glue for a abundant number of command line tools. Graphical user interface is much easier, you just point and click, like a baby not yet able to speak, but you are also powerless like a baby."

Jaqui
Jaqui

I used to like the CorelDraw! suite of graphics tools. but Corel implemented the adobe masking style in version 10 of CorelDraw! suite. made it completely useless. I can't work with that cover the rest of the image mask adobe uses. figure there is a perfect example of how changing gui apps screw the user from using the product. ;) can't use adobe's photoshop / illustrator ... because of the masking style. can't use Corel's alternatives, because they adopted the same masking style.

Sterling chip Camden
Sterling chip Camden

... has improved some over the years, but it's still far from ideal. I was all excited when I got SSH working on my Windows server, until I found out how little I could actually do within that interface.

medomoreno
medomoreno

I'm interested in your specific opinions of TermKit.

seanferd
seanferd

If you want or need more visual indicators, why are you in a CLI anyway? Icons? Use the GUI file manager of your choice. Text not being treated as text - gakk. And from the way I read the description, it sounds like UI unnecessary mode central. It's like The Ribbon for Sh. Javascript, really? Browser exploits against a secure shell. Sweet. I'd certainly be interested in hearing from folks with more informed opinions. I mean, more than the estimate of it being a bastardization. :^0

Neon Samurai
Neon Samurai

Much like the article mentioned, Windows is still very much a GUI centric design that seems to provide either limiting CLI (command.com, cmd.com) or overly conveluted control (Powershell). There are some nice tricks one can do with it though. The majority of my own CLI use is a cmd to "runas command.com" so that I can do basic admin stuff without logging the user out. msiexec and control.exe both become handy in those cases also. Offhand, what SSH implementation did you install on the server?

apotheon
apotheon

I have yet to encounter any coherent explanation for how TermKit gives us anything in terms ('scuse the pun) of usability and functionality that we do not get by being able to work normally at the shell within terminal emulator windows inside of an X Window System session, and to use GUI tools within that session -- including access to a browser. What the heck does TermKit do for me? So far . . . nothing I've seen. It just seems like a lot of effort to do "not much".

Neon Samurai
Neon Samurai

It may simply have been the demonstration of it running in a terminal window; perhaps it's more applicable as an Xorg replacement running on top of a raw terminal boot. If I want a GUI, I'll run a GUI. When I open a terminal window, it's because I want cli and scripting power. On first read, it seemed like an over-complicated way to implement what should simply be a command line popup attached to a GUI file explorer instead of a GUI explorer super-imposed over a terminal cli. Still, always interesting to see how folks are bending the code into new ideas. "Because I could" is a fantastic reason to do something new.

apotheon
apotheon

I got bored and skimmed after reading for a bit and failing to find any compelling reason to try to use a browser-centric UI to accomplish exactly the same tasks as the text-stream UI of the shell. Ultimately, my thoughts were pretty nearly identical to yours so far.

apotheon
apotheon

I agree with you on all points. Proportional fonts look nice in a book or magazine, but for code they're a terrible idea.

Sterling chip Camden
Sterling chip Camden

I understand the question that with all the graphical power available on today's computers, why are we limiting ourselves to cell-positioned text? In my opinion, it's because text is more expressive for many tasks, and monospaced text is actually easier to read when individual characters matter. YMMV.

Neon Samurai
Neon Samurai

It's one of those overly complicated setups that I always get half way through then just crack open a VM or reboot. I should give it another go though; if only to bang through the setup for learning purposes. (it'll be a while though, my current lab toy is an MS network. It's fully virtuall including the monowall gateway node. Fun stuff though a bit too much mouse clicking about for my liking and RSI. Still, I learn far better through the hands on imperitive and it was time I updated my AD setup skills.)

charlvj
charlvj

Cygwin would give you pretty much everything you'll need from a linux shell, and give you access to the windows programs. This allowed me to write and run some killer scripts on my windows box at work.

Neon Samurai
Neon Samurai

Putty gets you the secure remote terminal. It's nice because when you maximize or stretch the window, you get a nice big text area to work with. WinSCP gets you the sftp functionality for transfering files around though for that, Filezilla is also worth a look for that. FZ will send multiple files at a time and resolves file conflicts a bit differently. Now, having a solid SSH service on the windows side may really fill out the set by providing true cross platform file transfer with strong encryption. CIFS is convenient if your only dealing with Windows boxes on both sides but it's not terribly secure.

Neon Samurai
Neon Samurai

I'll have to look at that later. an SSH deamon combined with powershell may come very close to openssh into a *nix shell.

seanferd
seanferd

I've never seen that one. Since I don't use SSH often, I'm not terribly surprised. I've used PuTTY, and heard of WinSCP, but I don't think I've ever used it.