Why are terminal consoles still used?

Question

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?

Answer 1

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.

Answer 2

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,

See-and-Point

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.

Answer 3

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.

Answer 4

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.

Answer 5

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 ... )

Answer 6

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.

Answer 7

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
    fi
    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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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).

Answer 13

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.

Answer 14

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.

Answer 15

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?