Quote: Original post by plywood
But for the life of me, I can't figure out what the added benefit is to opening a bash terminal and meticulously keying in "sudo mkdir opt\a\b\c\my\directory" vs. just doing the same thing with a few clicks of a GUI desktop system.

Your example is weighted heavily in favour of the GUI - it is one of the tasks that GUIs are explicitly designed to support.

Consider a few of these instead:
- Change the file extension from .pak to .zip on 10,000 files: for f in *.pak; do mv $f `basename $f`.zip
- Delete all text files from a directory tree containing many other files: find . -name "*.txt" -delete

A GUI can do whatever its designer can imagine.

A CLI can do a whole lot more.

The Unix philosophy was to have many little tools, each capable of doing a single thing and doing it very well. Once such tool was the shell (sh, then csh, later bash and myriad other knock-offs), whose sole function was to join all the little tools into something bigger, the way complex proteins are built of simple atoms. The designers of the system did not know what the users would do, so they let the users decide.

GUIs are celebrated because they are fairly simple to learn and use. So simple, even people who wear suits can use them. That ease comes at the price of a lack of flexibility and extensibility. The price has rise higher over the years as "easy to use" has become synonymous with "works like Microsoft Windows XP," which means even Microsoft have found themselves criticized for innovating with the user interface of their desktop. You might note on their server product a number of tasks can only be done from the command line, but that product line is for advanced users in the datacentre who are already familiar with CLIs.

So, in short, many operations are not only faster using the CLI, but are impossible using a GUI unless the designer already anticipated it.

I am required by my employer to use Ubuntu, but I really use the GUI mostly to launch CLI windows. Worse, I have to use a web-based cloud interface for chunks of my daily work. The CLI is to the GUI as the GUI is to the cloud.

The gui is better for some things (I'd rather browse image directories with a gui that gives me thumbnails) and the CLI is better for others (mass operations, or convoluted operations).

1) The CLI has bash scripts that you can make and run on your machine or other machines. Do the same operation on several computers at once, instead of having to click through guis in person.

2) The CLI has pipes. There are tonnes of unix tools that each specialize in just one operation. With pipes you can chain information (or even user input) from app to app. This lets you do things like pipe an application's text output to grep then sort then tar. Since it is all a big chain, you can write an app that uses std::cin to get user input, and I can pipe a file to your app as that user input.

3) Dialogs have to be clicked on. CLI apps tend to not ask for user input as much as GUIs do (or like I mentioned you can pipe appropriate input to them). So, it is a lot easier to feed the commands into something like CruiseControl for automated code building.

4) GUIs aren't all that light weight. There are a lot of "simple" gui applications that take forever to start up compared to just running it at the commandline (especially if you already wrote a script that shortens the amount of stuff you have to type). I mean, why wait for a whole text editor to open up if I just need to see the file? You can cat/head/tail/less/grep a file at the command line and just see some text. (of course I assume you already had the CLI open and right there). If the text output is interesting enough, I could then decided to actually pop open an editor.

5) Use ssh. Sure you can x-forward over ssh, or use some other kind of virtual desktop tool. But you can work very quickly on remote computers using only the commandline. I did this all the time in school to do programming work on the school lab servers instead of having to go down the lab. Its the easy way to manage a web sever, NAS server, etc.

6) Its the extreme end of "learn the shortcut keys". There is no mouse to slow you down. Ie, if in Visual Studio you use the mouse to hunt for the compile key instead of hitting F7 you are wasting time.

7) It isn't a solve all thing. There are lots of pieces of information that are just overall easier to present to the user in a GUI. Like I mentioned, thumbnails. Trees, piecharts, graphs, and other information presentation tools make it a lot easier to see really detailed information at a glance. Sometimes GUIs present information better. They have tabs, windows, dialogs, and other information presentation that can give you a good look at all your options.

The command line is great, very fast once you know a few commands by heart, and GUIs simply don't lend themselves to automation. Most of the tools I write end up being command-line apps or, if they include a GUI, also expose most functions on the command line as well. The GUI tends to be faster for one-off jobs, but it's always good to be able to script the tool for big jobs or call it from another program.

Also, many times the GUI that you see is actually just that: a GUI -- and all the real work is being done by a command-line program it calls.