Michael Eriksson
A Swede in Germany
Home » Software development | About me Impressum Contact Sitemap

Advantages of command line over GUI


A common misconception is that the command line is a left-over from the age of dinosaurs, which has now been superseded by the superior concept of a GUI. This, however, is truly an error. Below, I will make some comparisons between a typical Bash-level command line and a Windows-level GUI setup. The statements assumes typical configurations for these tools; for other configurations and other similar tools, there may be a variation in detail.


It should be noted that “GUI” covers a greater area than “command line”, and that they are in no way excluding each other. (Consider by analogy weight-training and shot-put.) This article focuses on what a command line can do, and why it is superior for these choices. The GUI paradigm has other strengths, which are not denied; however, a GUI should be used in those areas, not to replace things that were originally done with the command line—and that are still done better with the command line. As a result, the below deals mostly with command-line shellsw vs. graphical shells; however, other areas are touched upon.

Starting tasks

  1. A command line has an easily accessed history, where it is possible to go up and down with the arrow keys, search for previous entries (even using regular expressions), and edit previous commands before launch. Several old commands can be grouped and edit, or saved to a file for later re-use. (In fact, for e.g. Bash, the history is automatically stored in a file that can be manually edited at wish.)

    I have never seen a GUI who has truly supported these capabilities; Windows has an extremely rudimentary support, with mechanisms like “last ten launched applications” or “last ten opened files”.


    Windows does have “Run command” (a miniature, fake, command line) and the DOS-emulator (a weak and user-unfriendly, but true, command line). However, these belong to the command-line camp, and cannot be used in the current comparison. (They would, however, be relevant in a comparison Unix–Windows.) Note, however, that the do not deserve to be mentioned in the same sentence as the likes of Bash, Ksh, Zsh, ... For someone used to the old DOS-shell, the Windows-shell may indeed look like an improvement on all fronts.

    Windows PowerShellw, which I am not personally familiar with, is also a command line. That Microsoft capitulated after twenty years of command-line disparagement, and finally provided a decent version, could actually be seen as a very strong argument for the superiority of command lines. Notably, no version of MS-DOS (be it as an OS or as an emulation) managed to reach the capabilities that Unix-shells already had in 1982 (the year MS-DOS was released) in the roughly twenty-five years until the release of PowerShell.

    Notably, the command-line history automatically includes all commands launched on it—many of which would occur within an application in a GUI centric environment. Each of these individual applications would need to provide a history. Consider a simple task like making a tricky multiplication with a “virtual calculator”: Enter “142536435” with the mouse on the virtual keys, enter “*”, enter “89735389”, enter “=”, realize that “142534435” was intended, start over again. In Bash, OTOH, expr 142536435 \* 89735389 can be entered with the keyboard; and when the error is seen, just recalling the command and changing one digit is enough.

  2. If a command-line user wants to call a certain program several times with different parameters (e.g. to use several browser instances with different security settings, or to do a certain task on different files) he specifies the first group of parameters on the command line, recalls and edits the command, recalls and edits the command, ..., until all variations have been launched.

    A GUI user finds the right entry in the application menus, launches the application, goes into the settings in the GUI and makes corresponding changes (e.g. JavaScript On/Off, cookies On/Off), goes into the application menus, ...

    Or does he? More likely than not, the application launched will refuse to be run in more than one simultaneous instance, or insist upon using common settings for all instances—meaning that he cannot do this at all...


    As time goes by, it has become increasingly more common to not provide command-line options that would have been included as a matter of course in the nineties. This has the regrettable side-effect that the power of command lines is unnecessarily diminished.

  3. Similarly, the ability to specificy options on the command line can make life a lot easier. Consider software DVD players: With e.g. Mplayerw (a command line based player) it is easily possible to specify options like language to use for subtitles and audio, volume, and similar, on the command line. A particular advantage is that by directly specifying the title and/or chapter to play, the unethical and customer-despising forced copyright-warnings can be skipped—as can overly long and time-wasting menus. In contrast, GUI based players force the user to make such specifications in the GUI, which is a major PITA (considering the lack of respect for default settings in the DVD industry). Worse yet, the poor user is often forced to use the DVD-internal menus, which are typically absolutely inexcusable (cf. TODO). Contrast Mplayer with the absurdity Kaffeinew or one of the typical commercial players for Windows.

  4. A command line makes it easy to call several commands at the same time, make execution of one command conditional on the success of another, and to use the concept of a pipew—one of the greatest usability helpers there is.

    I have never seen a GUI with anything similar.

  5. Generally a command line provides powerful programmatic abilities fully comparable to a programming language, but usable with very little effort.

    A GUI would typically require the writing and compilation of a full blown program for the same effect. (However, Windows does have some GUI-scripting abilities.) In any case, this requires leaving the Windows-shell to use a specific application to write the program/script/whatnot.

Use of input/output from one application with another

On the command line this is trivial, by use of the aforementioned “pipe” concept and the ability to print output on several different output-/input-streams that can be redirected to/from files and applications.

The typical set of GUI applications will require either manual copy-and-paste operations or the manual saving and reading to/from files.

Example: Assume that we have three applications that respectively down-load the contents of an URL, convert a HTML page to plain-text, and count the number of words in a plain-text page. Assume further that we have want to find out the number of unique words on a certain webpage. In case of GUI applications we have to

  1. Start application one. Download the webpage. Possibly explicitly save the webpage to a specific name (many down-load tools save to a file automatically). Close application one.

  2. Start application two. Open the right file. Convert the file. Save the file. Close application two.

  3. Start application three. Open the right file. Read the output. Close application two.


In e.g. Windows the likelier approach would be to find the file and start an application on that file, rather than starting an application and then opening the file in it. In most cases, however, the amount of work will be the same, or even higher, this way, because only the most popular applications tend to be found in the “open with” short-lists.

On a command line, app1 <URL> | app2 | app3 will readily provide the answer.

Reuse of existing tools vs. re-inventing the wheel

A understandable reaction to above example would be that these three functions should be included in one single tool—as it may well be in a command-line context too.

In many cases, this will make sense; in many others it will not. Above it could make sense to have a feature of a webbrowser that simple tells the user how many words are present in the page he watches; however, it will not generally be possible to predict or correctly implement every conceivable weird thing that the user may want to do—nor will it be viable to implement each wish for each application, each document format, etc.

Here a command line brings great advantages: Existing small tools can easily be combined in a variety of ways to give even a semi-proficient user almost any piece of functionality he wants. The same is not true, even by a long-shot, for GUI applications. (There are some attempts to gather very common functionality, e.g. spell checkers, in generic plug-ins, and to provide plug ins tailored to frameworks like Eclipse for popular tools; however, these are very far from having sufficient generality at this point of time—and they are mainly intended for application developers, not end users.)

Consider e.g. changing the above requirement to count all unique words: Only very rarely will a GUI tool bring this functionality; on the command line, it suffices to change the last application in the pipeline (or precede it with an extra filter, so that the last application is feed a unique list to count).

A more advanced example: What kind of renamings, moves, deletions, searches, etc. should a user be able to do where files are concerned? Here there are basically three schools:

  1. The Windows school proposes that the user is given access to the barest minimum that can be used without rendering the system useless.

  2. The Midnight Commander school proposes that as many use cases as possible should be thought through and implemented.

  3. The Bash school proposes that the user should be given strong basic abilities and be enable to extend these on his own with ease.

The Bash school will win by several horse-lengths, at least when focus is on accomplished users. Just to give one example: What file manager provides the ability to find all files in the current directory that begin with an “A” and has a third letter that is not “c” (a name length of at least three letters assumed) and rename them to the old name concatenated with the first line of the file (files assumed to not be empty)?

Try the following Bash snippet:

for file in A?[^c]* do suffix=$(head -1 "$file"); mv "$file" "$file$suffix"; done

(No fear: This is actually relatively straight-forward for the proficient user. It does, however, contain an extra assumption of no sub-directories being present. If needed, this can be corrected using find or test.)


Why would anyone want to do that? Why should I take such weird wishes into consideration when I write an application?

Frankly, what the user wants or do not wants is not for you to decide—he may very well have a valid reason to do this. The fact that so many modern companies (above all, Microsoft) presumes to decide the exact extent of what should be possible with their applications, is one of the greatest problems with modern software. A good software enables the user to do whatever he wants to; it does not restrict him.

Providing extra little nice-to-haves, like the word count above in a browser, is quite in order; making an application hard to use with other applications out of a short-sighted view on what users may want to do is not. Just adding the ability to read from stdinw and write to stdoutw and to activate a certain (already built-in) conversion from the command line, can make a world of difference.

Consider a simple thing like printing: Under Windows printing of a particular file typically involves starting the corresponding application and printing from it; under Unix the file is just sent to the printer, possible after being sent through a conversion filter. The Unix version is usually faster, less memory intense, less dependent on having certain applications installed, etc. What if the typically Windows application (that supports a typical file format) where to include a command-line switch that turns it into a minimal filter from the one file format to e.g. PostScript? Much would be gained, and the effort would really not kill the developers. (Assuming, obviously, that they work with a sound architecture and design—regrettably, not always the case.)


A few months after writing the above, I found myself with the need to identify which several files with the ending “.html” did not have an empty third line.

I used the following:

for file in $(find -name "*.html") do echo -n "$file:" sed -n ’3p’ $file done|grep -v ": *$"

(Note that this assumes that no third line ended with a “:” and that all files where at least three lines long—of which I was certain.)

Batching and automatization

A GUI is inherently interactive, and attempting to do things without interaction, bind several things to one command, launch an application (or a set of applications) for a certain task at a certain time, etc., is very hard. Even with tools and scrips that have the capability of simulating user interaction, this is error-prone at best: There simply is no reliable way to do things like this in today’s GUI environments. On command-line, OTOH, it is trivial—in fact, the greatest potential complication is that “modern” applications have been written without command line supported, which unnecessarily weakens the command line.


Generally, a GUI tends to restrict the user, and a command line to enable the user. Consider, e.g. the ability to use tab completion, aliases, own shell-scripts, and similar, in Bash; and contrast them with the rudimentary (or entirely absent) correspondents under Windows. A thorough discussion of all such abilities would make this article at least twice as long as it already is.

Advantages for beginners

A GUI can bring large advantages for beginners and very casual users. This is laudable, and should be encouraged; however, it must not be used as an excuse to limit the users who actually want to move on. Any organisation that is content with its interface when raw beginners can use it, should be condemned: A truly good UI, be it graphical or not, should make ease of use greater for everyone—not just beginners. (And, trust me, e.g. Windows, Word, Lotus Notes, ..., are absolutely abhorrent for a true power-user—user-unfriendly, limiting, frustrating, even sometimes sabotaging.)