As we all know, terminal consoles come from a time where there wasn't any chance of graphical interfaces, so the need for them is more than obvious.

With the appearance of graphical interfaces, many new applications were possible, but also most of those text-only programs moved to its graphical counterpart.

However, terminals persisted, and not only that: there are services that usually mention this as a feature. The most common example on hand is hosting services.

Of course, this means that, instead of clicking a button and editing a file, a user needs to memorize hundreds or thousands of commands and then do something like

sudo nano /www/var/html/myfile.html

and then navigate with a graphical cursor to edit something and then ctrl+X and Y and choose file to save to. In other words: the anti-usability at its best(worst)

The same can be seen for many other commands, the above was just an example. A very easy one: WordPress 1-click install vs install WordPress from command line

So my question is: is there a logical reason why terminals are still used (basically, a technological reason, or a security reason) or is this just a cultural thing that persisted some way despite all its issues?

EDIT: Adding another case: git. I know there are GUI for git, and they're far more user friendly than git on terminal. Then... why does the terminal version exist?

  • 3
    I have removed all comments on this post. If you (anyone) have an answer to leave then please do so, but this is not a discussion forum - if you have conversations you want to have then then take it to User Experience Chat.
    – JonW
    Commented Dec 2, 2016 at 10:19
  • A small point of order: if a file requires "sudo" to edit, you would probably need to enter a password, or at least answer a challenge, if you tried to edit it in a GUI app — assuming you had equal privileges in both interfaces.
    – Tim Grant
    Commented Dec 31, 2016 at 0:11

15 Answers 15


From a UX perspective, terminal consoles have a few key advantages over GUI's. These advantages are rarely relevant to end-users, which is why CLI's are used almost exclusively by technical users and "power users" these days.

Things done in a terminal are easily repeatable.

Imagine needing to configure 5 computers for some purpose. For this small number, it's probably not worthwhile to create an automated solution to configure them all. You'll just tweak the settings of each.

On a terminal, it's simple to copy and paste the commands. On a GUI, you might get familiar with where the configurations are stored, but may still be left with a fair deal of clicking. Mistakes are more likely.

This also is relevant to documentation and technical help. Providing four lines to copy and paste into a terminal console might replace a couple paragraphs of explanation of how to click into various admin tools (especially since the GUI directions might only be perfect for one of several interfaces, see “GUI interfaces are countless” below).

Tracking/auditing is easier

A command-line interface (CLI) retains a record of what you've done, which you can easily extract and keep. When something goes wrong your boss asks, "Are you sure you did it exactly right?" you can have evidence to prove you did. Even if you did make a mistake, you can more easily see it and learn from it.

Scripting/automating is nearly as easy as entering commands

Everyone knows how to use a mouse to open a file in a GUI. Far fewer people know how to make that happen automatically. With a CLI, automating the task can be almost as easy as typing it in by hand.

Technological Constraints can still make CLI's compelling

Logging into a GUI box remotely requires a fair deal of bandwidth, and latency (delay in the connection) can make the experience frustrating. A CLI remote login has a much lower bandwidth requirement, since it is just transmitting a little text back and forth. And latency is much easier to deal with when you are typing, than when you are trying to hover a mouse over an icon.

A CLI can be used for Input/Output

Some have called this The Age of the API, where systems are built on top of systems. A CLI allows a similar interoperability. In the question's example about Git, it would be possible to hook another "enterprise system" - such as a defect tracking system.

Compared to a SOAP or even Rest API, CLI commands can be easy to develop and test.

There are just a few standard shells; GUI interfaces are countless

If you log into the GUI admin interface of a few different web hosting services, you’ll probably see that they are all different. It’s not hard to poke around and figure out where everything is, but it takes time. Next year, the host may have upgraded their solution, and now everything is in a slightly different place — one more thing to learn.

That hosting service probably still uses the same CLI. The new version is backward compatible with the old. Users familiar with Bash, PowerShell, or whatever CLI is on the system can eliminate the ramp-up time spent familiarizing (or re-familiarizing) themselves with that particular GUI.


In short: command lines are language; language gives expressiveness.

An example of a text interface that you use: Google Search. Imagine if you couldn't type your queries as text into Google, and had to select documents you wanted from a menu of choices (like the erstwhile Yahoo web directory).

Jakob Nielsen, the usability expert and user-experience researcher, wrote with Don Gentner an article called "The Anti-Mac Interface":

Gentner, D., and Nielsen, J.: The Anti-Mac interface, Communications of the ACM 39, 8 (August 1996), 70–82

In it, the authors point out deficiencies in many principles that go into "GUI" interfaces. For example,


The see-and-point principle states that users interact with the computer by pointing at the objects they can see on the screen. It's as if we have thrown away a million years of evolution, lost our facility with expressive language, and been reduced to pointing at objects in the immediate environment. Mouse buttons and modifier keys give us a vocabulary equivalent to a few different grunts. We have lost all the power of language, and can no longer talk about objects that are not immediately visible (all files more than one week old), objects that don't exist yet (future messages from my boss), or unknown objects (any guides to restaurants in Boston).

They continue:

If we want to order food in a country where we don't know the language at all, we're forced to go into the kitchen and use a see-and-point interface. With a little understanding of the language, we can point at menus to select our dinner from the dining room. But language allows us to discuss exactly what we would like to eat with the waiter or chef.

The whole article may be worth reading, and contains many answers to your question.

So language (a command-line) lets you have a richer experience. But as you say, this does not mean that language is better, as illustrated this example that (probably coincidentally) neatly turns the above example around:

Using a command-line interface is like having to learn the complete Korean language just to order food in the Seoul branch of McDonalds. Using a menu-based interface is like being able to point to the food you want and grunt and nod your head: it conveys the same information with no learning curve.

-- Joel Spolsky, User Interface Design for Programmers, p. 76

Which is better, a GUI or a text interface? The text interface requires more time to learn, in return for being more expressive and powerful. Whether it is worth it to you depends on how long you intend to live in that environment, and how rich an experience you'd like to have.

The GUIs of contemporary applications are generally well designed for ease of learning, but there often is a trade-off between ease of learning on one hand, and ease of use, power, and flexibility on the other hand. Although you could imagine a society where language was easy to learn because people communicated by pointing to words and icons on large menus they carried about, humans have instead chosen to invest many years in mastering a rich and complex language.

Note that learning the "command-line language" (a Bash-like shell in a Unix-like environment, or perhaps the Windows equivalent) opens up to the learner at once a large number of potential experiences. So many have chosen to invest in this learning, and I for one can say it has paid off handsomely.

Finally, to answer your question on why services (such as hosting services) advertise text interfaces as a feature: imagine you're in a foreign country where very few speak English, somehow struggling with gestures and the like, and you see a sign on an establishment that says "We speak English here". (Similarly, depending on where you live, you might have seen signs saying "Se habla español".) The advertising you mention is similar: for those who are literate in the command-line "language", this amounts to an invitation that they can expect to have the rich experience of being expressive, without being limited to the graphical interfaces that have been already thought up and implemented.

  • 17
    This is beautiful, I'd like to pin it on the wall of the people promoting Matlab/Simulink for embedded coding in my company. I think it's a good simulation tool, but now I can just grunt, and it often takes much longer to grunt and point until I get what I could have coded in seconds.
    – CodeMonkey
    Commented Dec 1, 2016 at 11:52
  • 7
    Just to be clear, The Anti-Mac interface does not mean the authors are/were (in 1996) themselves anti-Mac, nor that they are critical of the Mac's usability. It is just an exploration of what happens when you reverse the principles of GUIs that were more clearly laid out by the Macintosh at that time. (It's not a Mac versus Windows versus Linux thing; the "Mac" in the title basically stood for modern GUIs, and that's a compliment.) Commented Dec 1, 2016 at 16:37
  • 28
    The linked article on "The Anti-Mac Interface" really points up what is, to me, a fundamental flaw in the GUI interface design, that "the interface should be based on metaphors with the familiar noncomputer world around us...". But what if the metaphors AREN'T familiar to the user? Documents, paper folders, desktops, trash cans? Maybe they're familiar to people from Western white-collar backgrounds, but that's a long way from including everyone who might want to use a computer.
    – jamesqf
    Commented Dec 2, 2016 at 2:49
  • 9
    @jamesqf right, especially since many of those common concepts nolonger exist anywhere except the digital world. The digital world is going to have to start standing on its own legs. Concepsts have to be able to have a digital life without reliance on realworld counterparts, because soon there will be people who have never seen a folder cabinet.
    – joojaa
    Commented Dec 2, 2016 at 15:45
  • 5
    "Whether [learning a text interface] is worth it to you depends on how long you intend to live in that environment, and how rich an experience you'd like to have." Excellent point. Usability depends on the use case. Any interface meant to be used once or infrequently should focus on simplicity and discoverability. GUIs can excel at this. Any interface meant to be used all day long for years on end should allow users to become very efficient, even if it means learning many commands, key combinations, gestures, or whatever. Those who use Vim, Excel or Photoshop all day learn all the tricks. Commented Dec 6, 2016 at 20:00

The long version

The answer's basically included in your question itself:

a user needs to memorize hundreds or thousands of commands

Switching that to hundreds or thousands of buttons would not be an improvement in usability (and even if done would be much much more limited than the text command line.)

If you tried to build a GUI general-purpose enough to cover every task that gets done in a terminal window, your GUI would be either be unusably complex or unusably limited in functionality for a significant subset of your users. Take your examples, for example: "one-click install" is great if all you want is the default settings, but it's insufficient for anything else. Editing a single file in a terminal may look complex, but terminal users routinely chain multiple text utilities together for specific purposes; working at the command line is usually a lot more similar to writing short, single-purpose programs than it is to clicking a button to perform a predefined task.

Most tasks which can be improved by moving them from the command line to a GUI, already have been -- if you don't want to use nano (or vi or emacs or whatever) there's no shortage of GUI-based text editors to choose from, for example. (Though if you're already on the command line and just need to make a quick change, it's quick enough to just type vi and make that quick edit without ever reaching for the mouse.)

But nobody's ever going to write a GUI able to, say, find all the files within a specific directory whose name matches a given pattern, then perform a search-and-replace within them, wrap the originals in a tarball and push it to another server -- because that would be an insanely overspecific task for a GUI to handle. But when you do need to do something specific like that, it's simple to pipe together a few UNIX utilities to do so. And to capture that in a shell script so you can do it again every week from now on.

Developers need to do insanely overspecific stuff like that all the time. The terminal is the most efficient and easy to use UI for that sort of task.

The short version

The command line trades away discoverability, in exchange for efficiency and flexibility.

The user has to have learned the commands ahead of time, they can't just dig around in menus and toolbars to find them as in a GUI. But once learned, all of those tools are a just handful of keystrokes away, and can be combined in novel ways as needed (while in a GUI every task has to have been thought of ahead of time by the designer.)

Followups in response to comments

The comment threads throughout this question have been culled a couple times now for chattiness, but since the same points seem to keep coming up, I'd like to address them here:

  • You don't really need thousands of commands, twenty or thirty will do.

True! Sort of. The problem is the 20 or 30 commands you need aren't necessarily going to be same ones the next guy needs -- a simplified GUI containing only the subset of commands you routinely use won't be sufficient for that other guy; and won't work for you either, the first day you need to do something that isn't routine.

(Secondarily, once you account for all the various commandline options on each of those commands, as well as the ways they can usefully be piped together, you're really at a lot more than 20 or 30 interactions that would need to be supported in your personalized GUI...)

A GUI has to be designed to a particular purpose. The command line by contrast is general purpose -- it can be all things to all people, because if the functionality you need isn't built in, you can add it yourself.

  • That example you gave of an insanely over-specific task that nobody would build a GUI for: somebody did.

True! I walked right into that one, yup. I changed the example to make it slightly more insanely over-specific (but no less plausible).

GUI wrappers have been spun off for plenty of command line tasks, and certainly are useful (I spend much more time in the github GUI than using git on the command line, for example) -- but each of those is just one subset of the many types of tasks the command line is used for; my point there was more that no reasonable GUI could cover all, or even anywhere close to most, commandline tasks. (Or, heck, even those for just git itself; I do still frequently need to drop back down to the command line for things the GUI front end can't handle.)

  • Discoverability ("The command line is more discoverable than you think" / "GUIs aren't as discoverable as you think")

I'm using the term "discoverable" in its strict sense here: a new user can figure out how to use a program by just using the program. i.e. if you just bang away at it for long enough, you'll be able to figure out how it works without resorting to external resources. (I am definitely not saying that that's the only or the best way for a user to learn how to use something; just that it's a potential advantage GUIs have over the CLI.)

I will happily concede that poorly designed GUI interfaces don't necessarily facilitate discoverability.

I don't agree with the several comments (some deleted, some still current) suggesting that the command line does facilitate discoverability, to any real degree. If you have to read the man page in order to figure out how to use a feature, that's not discoverability; that's learning. Which is great, but it's a different thing. I don't think there's enough consistency in the command line options for various tools to make the argument that learning one tool helps you understand the others; and there's no reasonable way for a CLI user to discover the existence of tools they don't even know about yet (no, ls /usr/bin doesn't quite cut it; that's more analogous to "give me the index to the manual, in alphabetical order".) There are some helpers and shortcuts, such as tab-completion, but those are more useful as a reminder after you've learned something than they are as a way of learning it in the first place.

  • 11
    I think even the discoverability point is arguable. Up-front yes, GUIs can show you what you can do. But CLI's also let you discover things as you need them, after getting over an initial hump to learn some conventions. For complex tasks I think it could be argued that discoverability can be higher in CLI. The preponderance of video tutorials for how to do things in GUIs is a sign that discoverability is only skin-deep in many GUIs. Commented Dec 3, 2016 at 2:14
  • I believe FAR is the GUI tool you are (not) looking for :-P . It does find and replace, in files, with pattern matching on the file names to apply it too. I've not used it, but I suspect it also let's you make backups. :-P I agree with your general point though. Commented Dec 3, 2016 at 9:26
  • About your last point, fish is a shell that advertises discoverability. I don't think it has succeeded in this as much as it advertises, and definitely not as much as GUI's, but this may be because I already knew bash. Just thought I would bring it up.
    – trysis
    Commented Dec 4, 2016 at 4:43
  • 1
    @IT Bear: Why didn't your 14 year old self get a copy of "Linux For Dummies" (yes, there really is such a book), or any of the perhaps thousands of decent introductory books & online documents? Why this (IMHO really dumb) idea that one should learn by trial & error?
    – jamesqf
    Commented Dec 8, 2016 at 5:51
  • 1
    @ITBear: to quote Sumudu... 'after getting over an initial hump to learn some conventions.' This is what your 14 yo self failed at: getting over the initial hump. Well designed GUI tools can help get you over this initial hump to basic use, poorly designed tools can be much worse. I remember my own teenagish-self being gifted a book on 3-D programming which included (on CD) some then-popular tool for 3-D modeling. It had dozens of sections in the menu and tiny icons on toolbars, the menu items were all abbreviations, which opened up undocumented dialogs. I gave up on it pretty quickly too.
    – Mr.Mindor
    Commented Dec 8, 2016 at 21:17

So my question is: is there a logical reason

People can type faster than using a mouse.

An anecdote:

In a past life I was part of a small team working on a piece of software for a niche market. This was in the 90s when the market dominant piece of software had been a command-line tool. This demographic wasn't necessarily tech-savvy so we built a piece of software that was a lot easier to learn given it had a GUI.

It was modestly successful but, in the end, we never were able to dethrown the industry leader. Part of that could be blamed on the fact that they were simply the embedded option and it's always a challenge to upset the incumbent. But a big part of our inability to win over customers from the other software was that the people that had worked on the command line tool liked it. They knew the commands, they were fast with it, and could do everything quickly with a few keystrokes.

So while it was a rather cumbersome tool to learn, once learnt, it was an incredibly powerful and fast tool.

Lesson learned for me was that GUIs aren't any better or worse than terminals/command lines. They are simply different. Sometimes one is better than the other for particular tasks, but it's impossible to say one is simply better than the other. It all depends.

  • 18
    This answer points at a big core of the positive UX components that TUI/CLI has that most GUI UX people have just missed. It's why people who've climbed the learning curve of vi-like controls have a vastly better experience using them than conventional interfaces, for example.
    – mtraceur
    Commented Dec 1, 2016 at 7:43
  • 1
    Great answer! I like how it points out that depending on the user/target market, and the task at hand, a CLI could actually have better UX than a GUI. Different tools for different jobs. If I need to copy a file from a network drive to my desktop, mouse & GUI all the way. But if I'm copying every file in a folder, except for the ones that are older or same size, excluding *.lnk and *.thumb files, to a folder on network drive, and want to see what files already in the network folder were not present in my original folder, CLI tools actually make that job easier.
    – IT Bear
    Commented Dec 7, 2016 at 0:02
  • 1
    & to compliment this — often the computer is faster in CLI than the GUI too. E.g. moving a large directory structure can be much quicker with mv than dragging & dropping through Finder Commented Dec 8, 2016 at 18:56
  • Expert-friendliness vs. beginner-friendliness.
    – DevSolar
    Commented Dec 9, 2016 at 14:08

I'd argue for two main reasons, neither of which is universal. But, both reasons are very good reasons to prefer doing at least some things on the command line:

  • Programmability. It is leaps and bounds easier to code against standard IO than it is to programmatically manipulate a GUI -- or to write custom integrations for the macro runner for each application you want to automate or integrate with.
  • Efficiency. When you want to edit myfile.html, you already know the name of the file and the editor you want to use. Quite often, it's just faster to type what you're thinking than it is to translate what you're thinking into a series of coordinated mouse movements in a hierarchical GUI -- to find your editor, and to find your file. (It's notable that the trend in GUI's has been to provide mini-consoles, wherein you can simply type the name of the program you want... )

In your example:

sudo nano /www/var/html/myfile.html

If I already know I need to edit myfile.html as an admin, and if I'm familiar with my UI (the console and my usual editor) it takes 2 to 3 seconds to type this:

sudo nano /w <tab> v <tab> h <tab> m <tab> <enter>

When I'm already in my working directory, it takes me roughly 1 second to open a file in vim if I know the first 1 or 2 letters of the file I'm looking for.

That's even faster than when I have a solution already loaded in an IDE -- even when I know the full path and filename. In a GUI, I have to visually scan and navigate an alphabetized hierarchy to find my file. For me, that's probably 5 to 15 seconds, depending on how big the file hierarchy is.

It doesn't sound like much, but it feels like a lot. And, if you're in and out of hundreds or thousands of files and operations on those file per day, the additional 4 to 14 seconds per file may be notable. (Especially if your boss is comparing you to your command line wizard counterpart ... )

  • 4
    Totally agree with this. If you do already know how to use a terminal well, you don't need or want a GUI for a lot of things. I do pretty much everything from bash on my Linux desktop. I use directories to keep my files organized, so I can quickly cd to where I know something is. I have a findiname() shell function that runs find -iname "*$1*" (actually fancier than that: handles multiple args), so I can pattern-match filenames in a subdirectory. I use git gui and gitk because they're actually really nice, but I don't use a GUI file manager. Commented Dec 1, 2016 at 4:02
  • I usually have a few tabs open in a Konsole (terminal window), with a screen session in one of them with about 10 shells open. I tend to keep the same numbered session cded to a similar place, so I can very quickly switch contexts without using a boatload of RAM or cluttering up my alt-tab window switching (browser windows, pdf viewer, emacs, not much else) Commented Dec 1, 2016 at 4:04
  • 2
    In Eclipse I'd type <Ctrl-Shift-R>myfile<enter> Commented Dec 1, 2016 at 22:28
  • @immibis I can't speak for Eclipse ... Does that give you directory and filename tab-completion?
    – svidgen
    Commented Dec 1, 2016 at 22:38
  • 1
    @svidgen Not tab-completion, because tab switches to the next element. Ctrl-Shift-R opens the "open resource by name" dialog, with the focus on the textbox where you type in what to search for, and the first search result is always selected by default, and <enter> accepts the dialog (opens whichever search result is selected). You can't type a directory name in this dialog, but if you have files with the same name in different directories, you can use the up/down arrow keys to select one. Commented Dec 1, 2016 at 23:01

A command line interface (CLI) is not so unfriendly as the question makes it sound. We could similarly argue that a point and click interface is bad because it hides internals and makes it hard to compose complex commands.

Let us imagine a small child that does not yet talk, but instead points at things. Yes, it gets some tasks done, like asking for bread or drink at the table. But once the child learns to speak, they rarely revert back to pointing around. This suggests that speaking is more powerful than point-and-grunt. Yet going forward, we do not replace everything with writing letters.

Now, many graphical user interfaces are like the child example, point and click. The command-line interface is more close to talking to a software, or even more appropriately thinking texting a friend which is slightly more demanding than speaking.

In a ideal world you would not think that a CLI is a horrible antithesis to UX, but a complement of the GUI. It does not have to be either/or. Just like an adult in a foreign land may revert back to pointing. You should be able to choose what is appropriate for the task.

Some misconceptions

  • A command line requires you to learn thousands of commands.

    On the contrary, usually you need to know a dozen at most to be effective. Just like in a graphical user interface you still need to know what you're doing. In many places where you have many applications installed you end up in the same problem. You can simply not use program XYZ unless you know the name of program XYZ and find it in the GUI for you to launch.

    Knowing nano is a text editor is obviously a memorable thing, just as much as knowing that notepad is a editor.

  • A command line is hard to learn

    Not really, it is usually very simple. However, since only somewhat advanced users would use it means it is often geared towards them. That does not mean the concept is hard; just that it is not intended for casual use.

  • a command line is less discoverable than GUI

    Sometimes GUIs are, sometimes they are not. Command line interfaces are discoverable, at least good ones are. Likewise not all GUIs are very usable. In fact a very bad command line interface is better than a bad GUI. The command line is actionable -- you can easily encapsulate the bad command line to suit your need adequately. A bad GUI is a bad GUI -- there's not much one can do about that.

  • A GUI is easier to use

    Sometimes when doing simple tasks that they were meant to do, that is true. However, sometimes people get mired down by ridiculously simple things which are trivial to do but the GUI just does not let you do that. On a command line this is usually no problem: just take some other command to help you.

Is a command line bad UX?

Only if it's badly designed! Command lines and commands come in different packages just like GUIs. Most of them aren't particularity elegant. Yes, most of the GUI applications are crappy too. Some command line apps have a astoundingly good design and give a good UX while others don't.

There is nothing inherently bad in a command line. In fact, I have discarded applications as bad because they had no command line interface to speak of! I have also used some applications for years even when their GUI is crappy because they and a good command line interface. YMMV.

PS: It's amazing what you can do with a loop. What you'd spend days doing by hand can be done in seconds. If you value your own time, you use the command line.

  • 1
    The speaking child is a great simile!
    – ceving
    Commented Dec 2, 2016 at 12:18
  • 7
    I would argue that some recent GUIs are decidedly non-discoverable. Take the Windows 8 "Start" screen, for example: when I open it, there is NO indication that typing will do anything, nor is there any obvious way to access a list of installed programs. "Three dots" or "three bars" is not obvious as "click here for more options". And so on. Sure, all of those are easy once you know them, but that doesn't make them obvious or even discoverable.
    – user
    Commented Dec 2, 2016 at 16:23
  • 3
    @joojaa Exactly. There is a lot of focus on UIs being "user friendly" but lots of UI designers today seem to forget about discoverability. When there is no indication on the screen that doing Thing X will lead to Result Y, then doing Thing X to obtain Result Y is non-discoverable. Non-discoverable UI elements can be a great way to provide power user functionality (like pressing Alt+D to focus the address bar in a web browser which, IIRC, actually was originally discoverable), but it's not a good way to design elements of a UI that ordinary users can be expected to want to use.
    – user
    Commented Dec 3, 2016 at 5:22
  • 1
    @Michael Kjörling: Why should the interface to a non-trivial application/system be 'discoverable' rather than 'RTFMable"? Take for instance LaTeX vs MS Word/OO: I suppose if I used trial & error in the later long enough, I could figure out how to produce a decent paper with equations, graphs, pseudocode &c. (Though 'long enough' might exceed my life expectancy :-)) With LaTeX, I can easily look up whatever I need in a index, because it's language, not grunting & pointing.
    – jamesqf
    Commented Dec 3, 2016 at 18:05
  • 1
    @immibis they even had to add the «Press here to start» message when there was no activity after X minutes, because some people would simply stay waiting as if the desktop was part of the booting process, too.
    – Ángel
    Commented Dec 4, 2016 at 23:53

Well, I use terminals for nearly everything but a few things like image editing. I'd like to share my reasons for doing so, focusing on user experience.

the shell is a language for program composition

Terminals (and shells) are what allow me to have a conversation with my computer. I don't use the terminal to do things; I use it to communicate my intent to the system and have it do it for me.

For example, with a shell I can do incrementally more complex tasks. Anything I can do by hand, I can tell the system to do it itself.

# report status of service
systemctl status mariadb

# do it on foo.com
ssh foo.com "systemctl status mariadb"

# do it for bar-1.foo.com through bar-8.foo.com
for i in {1..8}; do ssh bar-$i.foo.com "systemctl status mariadb"; done

Please note that these three commands in turn require no retyping of anything if you know either the shell keybindings for history navigation and command line editing, history expansion, or even copying and pasting. The result of each command will be in the terminal for easy reviewing and comparison. Absolutely everything can be copied and pasted to anywhere in the system.

The equivalent of the last command with a gui would require me to login to each system through some remote desktop protocol and manually check the status of each service by moving a mouse around and clicking icons, sending mouse coordinates and clicks and receiving a video feed containing a wallpaper and windows and menus popping up. There is going to be no simple way to compare the results side by side. I'd need the protocol to either handle shared clipboards and copy the results to a file in my local computer, or handle that many heavyweight connections and resize the windows to hide the wallpapers and stuff.

Ok, now I want to be emailed if one of them goes down.

while true; do
    for i in {1..8}; do
        echo "==> bar-$i.foo.com"
        ssh bar-$i.foo.com "systemctl status mariadb"
    done > /tmp/services.txt
    if grep '^\s*Active:' /tmp/services.txt | grep -qv running; then
        mail -s "service failed!" [email protected] < /tmp/services.txt
    sleep 10m
done &

Simple enough. Now, because I've no clue on how to extract information out of a rendered gui (OCR?), I can't do the equivalent with gui's.

The problem I'm trying to get at with the gui way is that I have no way to tell the system things like for i in {1..8} or if grep ... with the gui, and it's really cumbersome to tell it "move the mouse to this coordinate, double click, and wait this estimated amount of time before clicking in this new window...", and that's assuming I can guess where the new window will appear...

I can do things with the gui, but it's not a language. I can't tell it what I want done so it can do it for me. I must do it myself.

easy to communicate

How would you give instructions to do a specific task to other people? In a gui you'd have to tell them to click on the fox, then the hamburger (if they understand that term), menu, menu, menu, tab, click, exit, click, etc. Sometimes it helps to post screenshots of the gui with big red arrows pointing at where they need to go.

With commands, you just... write them. If the actions are too complex and they trust you, they can just copy and paste the commands and be done with it.

storable actions

This might be obvious, but you can combine a complex set of commands, put them in a file and run it... it's pure automation; how can a gui compete with that?

shell keybindings, globbing, brace expansion, history expansion, etc.

I think most people that complain about the shell, do it because they end up typing very repetitively (it might also be because it still requires a lot more typing, though I'd argue that that's a plus).

The shell has many features that make working with it extremely efficient. The catch is that you must learn about those features. It's all in man bash and man zshall. It's too much to even scratch the surface here.

Well, the point here is that the shell provides many facilities to cut out the repetition in your work. Gui's of specific programs might something similar through history functionality and the like, but the shell works for practically everything.

terminal scrollback-buffer and shell history

I got my terminal configured to save the last 100000 lines for display. If I leave my computer for a while or don't revisit a terminal in some time, I can always scroll back and see what I've done involving any (terminal) program. I got my shell prompt setup to display a timestamp before and after I run a command. I can always tell how long a command ran without preemptively running it with time. It's so simple, but how would you do that with a gui? Implement some kind of video playback for the desktop to always be recording?

I also have the shell to save the last 2000000 commands in a history file. If I look at the file, not only does it have the commands, each one has a timestamp of when I ran it. Some months ago, my boss asked me to do some task I did a few months after being hired. I can't remember now but I remember I couldn't remember then. It was multiple complex commands involving some set of servers. Thankfully, I still held the commands in the history file. It was so insanely easy to just find them and re-run them. I was so impressed, I increased my history size limit by two-orders of magnitude. What would you do in this situation if everything you do was with a gui?

simpler to program

Programmers are also users. The ease to write terminal programs is also part of the user experience, and it most certainly is a reason why so many new programs are written to work for a terminal.

You don't have to deal with creating windows and widgets, and some rendering loop. You just get your arguments from an array and print some text to standard output.

Programming for a terminal instead of a gui also has another implication: text configuration files meant to be edited by hand. When was the last time you used a gui program and was expected to configure it by opening a file, editing it and then restarting a program? A user of a gui program expects to be able to configure it through the gui.

For the programmer, this means that not only does he have to write and read the configuration in files, but he must also implement widgets for it.

As the programmer will expect the user to use the widgets, editing the configuration file by hand is probably going to be a suboptimal experience. For the user, this also has downsides:

  • he won't be easily able to share the configuration with other computers and friends.
  • he won't be able to put comments on it as they'll be overwritten.
  • it might be problematic to track changes in version control.

single input and output

When I'm having trouble with some program and the error message is not too helpful, I run it with strace. The output of strace and the program are combined, and I can then see what it did that caused the error just prior to it printing the message that concerns me. If the program doesn't terminate after the first error occurs I can also pass the output to sed '/message/q' or the like to have it kill the program when the message is printed.

If I'm debugging in a gui, the error is probably going to come in some popup window, and the message will not have been passed through some system call. I can print everything the program did with strace, but finding the error in the never-stopping output is going to take more searching than I'd like. Gui programs also tend to do more stuff to get the same job done, so the culprit of the error is probably going to be hidden amongst many lines of message passing system calls that are hardly relevant to the task I needed done.

  • 1
    Re "... post screenshots of the gui with big red arrows...": And that assumes that neither party has customized the appearance of their GUI. I'm often irritated by people who assume that because they added HTML code to make text appear in a certain font or color, that my user CSS isn't going to override those to display text in the fonts & colors that I find easiest to read.
    – jamesqf
    Commented Dec 2, 2016 at 17:59
  • 1
    A nice supplement to your "easy to communicate" section that says how everything is a click: worrydream.com/ABriefRantOnTheFutureOfInteractionDesign Commented Dec 9, 2016 at 19:46

In a word: dysiconia. That's my own coinage, by analogy to dyslexia, and means that I have a really, really, really hard time trying to figure out what the stupid little pictures in a typical GUI are supposed to mean. I know they're supposed to be intuitive, but to me they're not. I think this might be true of more people that you'd suspect, or why else do GUIs often add text below their icons?

Of course with extended use I would memorize a few common icons (though I still can't understand why they're supposed to be 'intuitive'), but confront me with a new one and once again I'm clueless. Worse, there's no good way to look up a picture**. With an unfamiliar command, I can simply run "man strange_command", look in the index of the program manual, or use a Google search.

Humans are naturally verbal creatures - after all, language is what's supposed to distinguish us from the rest of the animals, isn't it? For those of us who use alphabetic languages, a good reading vocabulary in our native language would be upwards of 50,000 words. (Those with multiple languages might easily add 10K or more per language, depending on fluency.) We can either look up unfamiliar words in a dictionary, or deduce their meaning from context. Adding the few thousand (not hundreds of thousands) needed to use a CLI to this base is easily done.

All this is to say that for most literate* people, using a terminal/CLI is just an easy extension to skills they already have. Once one becomes familiar with with it, it is generally superior to graphical methods for any task that isn't inherently graphical (such as drawing).

PS for @nekomatic: For evidence, how about this: http://www.pewresearch.org/fact-tank/2015/10/19/slightly-fewer-americans-are-reading-print-books-new-survey-finds/ Literally the first link found searching for "percent of americans who did not read a book this year". From the link "Some 27% of adults said they hadn’t read any books over the past year..." and "The median number of books read by women was five, compared with a median of three for men..." If that's not functional illiteracy, what is?

*I suspect the popularity of GUIs goes hand-in-hand with the increase in functional illiteracy. Likewise voice input & output.

**Even ideographic languages like Japanese (and I think Chinese, though I've never studied it) have systems for looking up kanji in a dictionary.

  • 2
    Also, GUIs and their icons get redesigned. I found out that I was relying mostly on the color of the icons when Lotus Notes switched to a black/white design.
    – user24582
    Commented Dec 1, 2016 at 14:29
  • 8
    A motto of the original Mac design team was A word is worth a thousand pictures - which is why Mac menu titles and menu entries are words not icons, and is what the Microsoft Office designers forgot in the early 1990's and took a while to remember again. I think you need to bring evidence for 'increase in functional illiteracy' though?
    – nekomatic
    Commented Dec 1, 2016 at 15:39
  • @nekomatic Are you thinking of toolbars? The toolbars were never intended to be the primary or only user interface; they were intended to make commonly used commands quicker to access for experienced users. Every reasonably large piece of software tends to have power user functionality somewhere in its UI, which isn't required to use the software but offers time-saving features for the people who know about it when they have a use case that involves that functionality. It's quicker to click the "save" toolbar button (or press Ctrl+S) than to use File->Save, but they didn't remove the menu.
    – user
    Commented Dec 3, 2016 at 5:29
  • learn Chinese??
    – user67695
    Commented Dec 9, 2016 at 19:46
  • @no comprende: No thank you. Japanese was bad enough. I can't imagine the frustration of having to learn both a tonal language and ideographic writing system.
    – jamesqf
    Commented Dec 10, 2016 at 18:21

I may be on the wrong site, but...

User experience is not the only force driving programs.

Making and modifying a program is much simpler if you only deal with terminal input and output.

Humans are not the main user of terminal programs

The command in a terminal are the same ones the machine is using behind most of the graphics, this is a very good thing for testing parts of complicated things. Almost every line run through a terminal calls more than one program by linking them together, the graphic I get from a nice GUI can make it easy to learn about something quickly, but it doesn't help me tell the machine what to do about it.

and because I am here: focus

After using any program a lot you know exactly where to look for any information you want (if the writer isn't a jerk) having it be text is not much a hindrance once you've climbed the learning curve, and not changing focus to make the next change possibly using a different program is a positive.

  • 1
    The other answers provide a more complete picture, but this was my first thought as well. When I'm creating a new utility to perform That Which Has Not Been Done Before, I focus on the task at hand. The terminal is a minimalist interface that provides massive flexibility. Often I don't even need a GUI, because - as you say - my program won't be used primarily by humans, but by other programs. The interface is mostly for testing and debugging. I know this isn't a satisfying UX answer for "why are terminals still used", but it's certainly a valid one. Commented Dec 1, 2016 at 5:14
  • IMO the first point is a very important one. Often not much time is put into UI development. Commented Dec 1, 2016 at 22:30
  • Dwarf fortress is a great example of this. Great, popular game with really bad UX and GUI and a huge learning curve. But the concept and depth behind the game make the curve a good payoff for some.
    – user56701
    Commented Dec 2, 2016 at 7:56
  • 2
    Don't CLI apps offer a user experience? Commented Dec 2, 2016 at 12:36

Backwards Compatibility and Embedded Systems

That 30-year-old system that runs the avionics in a B-52 still has to be maintained. As does the micro-controller in the pump that feeds the water tower, or the system that runs the conveyer belts in my factory.

Disaster Recovery

It takes more time for the system to spin up the GUI from a cold start, time I may not have. If I need to get a backup machine running right now off an external storage device in a life-or-death situation, I don't want to sit around for an extra 60 seconds.

Remote Monitoring, Diagnostics, and Management

This applies especially when you are in a bandwidth-limited situation. If my primary, secondary, and tertiary wide-band communications links have failed, but I still have a 56k modem, I'm not going to drag that circuit down by sending GUI data over it. I'm going to use a CLI to remotely log into the routers so I can figure out what's wrong and get them working again.

  • 1
    Has point 2 ever applied to you? Commented Dec 1, 2016 at 22:29
  • Not quite life-or-death, but pretty close. And I've never worked in public safety or with medical equipment.
    – John Feltz
    Commented Dec 1, 2016 at 22:43

Because of two simple reasons

  1. It works
  2. It is powerful

Just to add to what had been said, because at the end of the day, a GUI is just a pretty front end to a command line utility.

Every time you click a button, a command is issued. There are actions that do not have a button, but there will never be a button with an action you will not be able to perform on the terminal.

As an example, in windows you can right click in any of your direct access icons on your desktop and you will be able to find there the command that is executed once you double-click it. You could directly input that in a terminal console and the same action will be executed.

In windows is more difficult to appreciate the simplicity and power of the command line because their shell lacks many useful features present in linux shells, like tab-completion, for example.

  • 7
    I'd quibble a bit about your assertion that everything doable with a GUI is also doable with a terminal: I wouldn't really consider e.g. drawing a picture in GIMP / Photoshop to be doable from a command line (even if, technically, those programs can be scripted), and trying to play e.g. a first-person shooter from a command line would just be awful even if it was technically possible. I suppose you could argue that, even if completely impractical, those things still could be done e.g. using terminal commands to fake mouse movements -- but, by the same token, on-screen keyboards exist, too. Commented Dec 1, 2016 at 1:04
  • 1
    I think you got a bit out of context, there you are talking about inherently graphical activities, and they do need a windows to display the content. You can still launch such applications from the command line, and they will open up in a window so you can interact with them. Commented Dec 1, 2016 at 1:40
  • 1
    The terminology used in this answer touches on some nice concepts, but presents an overly simplified view of the matter. For example, it's reasonable that someone may interpret this answer as saying that all GUIs invoke underlying CLI programs. But most GUIs call OS system calls, library functions, etc, just as directly as do TUIs/CLIs. And one can easily create a system where something can be done through the GUI which cannot be done on the terminal (just write/install the GUI programs for a task and leave out the TUI/CLI programs that do the same thing).
    – mtraceur
    Commented Dec 1, 2016 at 7:35
  • 1
    @joojaa Okay, so say you have a box running Linux kernel. You get a minimal Bourne shell and utilities (think lobotomized router or Android phone setup minimal, not busybox-with-all-features minimal) but no general-purpose interpreted languages or compilers (so no easy access to arbitrary system calls). iptables/nft CLIs not installed. But I include a nice GUI program for interfacing with the netfilter/conntrack subsystem of the kernel. Such systems exist. This goes against the absolute claim that there will never be a button for an action that you cannot do on the terminal.
    – mtraceur
    Commented Dec 2, 2016 at 5:26
  • 1
    "[Windows] shell lacks many useful features present in linux shells, like tab-completion" - nonsense. Windows PowerShell has just passed its /ten year anniversary/ and it has better tab completion than any Linux shell going - able to tab complete cmdlet names, cmdlet parameters, and the allowed values of the parameters if they're a limited set of accepted values, and often able to extrapolate from the return type of a cmdlet and tab complete on the properties of the output, before the cmdlet even runs... Commented Dec 3, 2016 at 8:14

I believe the terminal is a better solution for power users. It can get you right into the action, you can do any type of advanced task with it, and it's easy to develop for.

Sometimes the terminal is unavoidable. Some things just can't be done on a graphical interface, so you have to do it on the terminal instead.

Some people, like me, prefer the terminal over graphical interfaces for some applications. For example, I run a bot, and the terminal is my ideal development environment for coded applications (I also use GUI tools to code it, but the terminal is always my go-to for running it).


To be brief (kind of), since a number of good explanations have been provided, there are many essential systems where implementing a GUI is simply impractical. This is typically the situation with any server that is only going to do a handful of things and you need to be sure it has all resources available for just those tasks. If some of those tasks involve serving a GUI application, it should be provisioned for that, but if all a server is going to do is serve web pages, you would want only absolutely necessary programs so that it's doing nothing but serving those pages.

GUI programs are always going to have significantly more processing and data storage than most, if not any, command line program just due to the nature of requiring more information.

Git is another great example. You will mostly be using it on servers hundreds/thousands of miles away for which you can only interact through a terminal so that minimum resources are allocated to you communicating with the server. At that point, you'll want to be very familiar with the command line so you can work with it as comfortably as a GUI program.

  • 1
    As well as resources, a smaller amount of code on a server reduces the potential attack surface for security, and reduces the amount of software which needs patching (and maybe rebooting). This is one of the reasons Windows Server moved to a 'core' version with no GUI and is moving to 'nano' with a much smaller codebase and no GUI. Commented Dec 3, 2016 at 8:10

Control and precision

The use of terminal needs the knowledge of the commands that make it work. It is not intuitive nor easy for the beginner. But once the user knows the commands a lot of the functionality is faster to type than to find the element on the interface and interact with the mouse.

Some of the functionality of graphical interfaces might be behind security thresholds that protect the user from himself. Using commands on the console the user has absolute control on what he does.


Some answers have come close but none hit the mark.

The biggest reason for terminal programs. The very first and easiest thing to present to a user is a textual face. This textual face is in the language of the user. It needs the bare minimum amount of computing power and interface to allow communication versus all that is required to present a GUI. On top of that, a GUI requires far more memory and computer resources and power just to get to the point where a terminal would be. A GUI also requires more sophisticated hardware that can display it. Simple LEDs can present all the textual information needed to run the most powerful servers but cannot display more than very simple graphics.

Following on that, with regard to something to click, the ability to enter human language commands far exceeds the power one can use by checking boxes or clicking buttons. The range and precision one can convey in just a few simple words is far reaching and unrestricted. What does one do if the color "chartreuse" is not one of the checkboxes but it is an option in the program?

  • Back in 1998 when I got my own computer (Pentium MMX with maybe 64MB of RAM), limited computing power was a major reason for using the command line. I sometimes didn't run the GUI at all, so I was using a full-screen text login on the kernel's built-in console terminal (which supported multiple virtual consoles). That's not the main reason anymore: By now, with ~20 years of experience using bash as my primary means of doing day-to-day computing stuff like organizing files, I'm really good at it, and still only use GUIs for things they're actually good for. (e.g. gitk is great.) Commented Dec 1, 2016 at 4:17
  • 3
    Most GUI software is terribly bloated, though, since people care more about functionality than efficiency. That argument has merit, but things get pretty ridiculous when layer after layer of libraries and indirection and interpreters means that a modern web browser or spreadsheet running on a modern computer isn't much faster than 15 year old gui software with a lot of the same basic functionality running on a 15 year old computer. Commented Dec 1, 2016 at 4:19
  • 1
    While it's true that a CLI is a lot less taxing on a system, that's not really the reason they still exist today given that even the things we hold in our hands can present amazingly complex GUIs. It should also be noted that most CLI's don't use human language. They're still using software language.
    – DA01
    Commented Dec 1, 2016 at 8:13
  • 1
    @whatsisname: Forgot to mention explicitly that I run Linux (I meant to, but got lost while editing). I didn't switch from Windows, I started with Linux. (After using Unix shells on university machines via dialup from an Atari ST. Not dialup internet, just dialup terminal emulator. :P My dad's a retired physics prof who told me about Linux. He uses a Win10 desktop now, but still does a lot of his stuff on the Linux box over ssh). Totally agree that the DOS shell is not nice, and win9x is total garbage. Commented Dec 1, 2016 at 8:42
  • 1
    @DA01 I'd argue that we can't reasonably exclude those which use abbreviated human words from being called "human language" without it following that SMS slang and telegraphese are also not human language - and since both of those exist pretty much exclusively for communication between humans, this is absurd.
    – Darael
    Commented Dec 2, 2016 at 12:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.