Is the command line a popular choice thing, or do I have something wrong here?

In modern Linux there's dozens of fresh, robust, 3-D rendered GUIs, graphical-based APIs, and desktop interfaces that could easily implement the commands entered in to the command interpretor text-based UI on the GUI through a more robust featured program that encompasses GUI elements better.

What I am trying to say is, why is the command-line still so popularly used in 2013?

I mean I can agree that before both the memory in computers was so minimal that a fancy GUI would be starving the main memory, but nowadays memory DOES come cheap, GUIs are 3-D, we have mobile power machines getting better every day so to speak, so why are we still punching commands in to interpretor parsing terminal UI emulations?

Why isn't there a more robust and graphical way to implement the commands, only through a more modern GUI?

For example, how about "ls" or "list" as a button that will generate a table view of data, or "umount" implemented in a button that generates a table view of current mount points?

Overall, why doesn't a more modern implementation of the command interpretor come in to play, featuring the exact same control and capabilities just in a more convenient decor?

PS: I should add this here as well ... I'm not saying every command should be implemented with a GUI-based program with fancy widgets and such. I'm just saying that I figured we'd have a makeover of the command-line, or maybe that some ideas can be better expressed, optimized, managed, or cycled through easier with visual aspects than just "words". No means to start an argument, but to find out why nothing has diverted this way over so many years and advancements of graphics in operating systems/software.

closed as not constructive by Anthon, jordanm, Gilles, jasonwryan, slm Jun 21 '13 at 3:46

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Some of the resources posted here demonstrate the power of normal utilities over their graphical counterparts. – user26112 Jun 20 '13 at 20:34
  • 4
    "Now that we have computer animation, how come people still use spoken language to communicate?" – tripleee Jun 20 '13 at 20:50
  • @tripleee That's not a good example, I'm afraid. If we are going down that road, to say so metaphorically, why are we not killing other people, and peeing all over the streets in public, despite us being civilized animals? My point is that, aside with scripts, automation, such as bash or otherwise, some parts of a command interpretor's function can be better implemented with GUI-like elements, such as my example given in the main body, and many other ideas one can surmise. Point is, yes, some concepts should remain for their nature of convenience, but some areas may be better diverted. – Lester Bonker Jun 20 '13 at 20:56
  • 1
    To be honest, I think you need to learn to use the command line, only then will you understand. – Kevin Jun 20 '13 at 22:07
  • 7
    We have GUIs for ls; they're called file managers (Nautilus is a common example). But show me a GUI that lets me do the equivalent of ls -ltr foo*.txt | egrep -v 'bar|baz' faster than I can type it at a command line -- and then do the same thing again, but replacing foo by FOO. – Keith Thompson Jun 20 '13 at 22:22

A command line has a grammar - that is, a way to give lexically-identical strings different meanings based on position or relation to other strings.

You can express more things with a grammar than you can without. The best example is palindrome strings: you can't write a regular expression (the comp sci kind) that recognizes palindromes. Another example: you can't write a regular expression that matches "some number of 'a' characters, followed by the same number of 'b' characters".

Once you have a grammar, programmability comes along for the ride. You have a command line with a test, and a "while" loop? You can do arbitrary computation, which is another way of saying, "you can express more things".

Very few point-n-click interfaces have any degree of programmability.

In my opinion, the answer comes down to "a command line is just more expressive".

  • 3
    That is remarkably well-put. – user26112 Jun 21 '13 at 0:56

For me, it is all about automation.

Here is a series of little automation examples pulled from my shell history file (with some line splits):

# Modify remote urls for a few dozen git repositories
while read repo ; do (
    cd $repo; git-remote-mod-url 's/parad/para/g' locserv
); done < gits

# List the package repository that contains each package in a list
while read package ; do
    echo -n "$package " ; yaourt -Si $package | grep Repository
done < all-packages

# Make a bunch of directories based on the output of a script
./scripts/info/list.sh a | while read cat ; do mkdir $cat ; done

# Filter hundreds of files
for p in * ; do clean-text < $p/PKGBUILD | sponge $p/PKGBUILD; done

# Retrieve a list of items that might be suitable as examples for this post
grep -E '\<(while|for)\>' hist-zsh

# Get a list of orphan packages on the [AUR](https://aur.archlinux.org/)
for pack in * ; do (
    source $pack/info
    echo $pack
    curl -s https://aur.archlinux.org/packages/$upstream_name/ |
    grep '<td>None</td>'
); done

The commands provided by unix-like systems are flexible. You can chain them together to perform an uncountable number of actions. They're like blocks or LEGOs. Graphical programs are more rigid. It is generally difficult to interface them with other programs.

  • Yes, but that's not necessarily explaing to me why some parts of CLI-ing command parsing can't be transferred to a more convenient and graphical selection table view, layout, or otherwise efficient way to handle things than punching in text to be parsed. – Lester Bonker Jun 20 '13 at 20:52
  • I see. A while back, I thought about writing scratch-like shell for *nix beginners. I'm guessing that would be a much simpler version of what you are interested in. I believe what it really comes down to is that many systems contain thousands of commands (mine has nearly 2000 and according to my shell history, I have used about 750 of those). That would mean lots of buttons---lots of menus. In my opinion, it's easier to just remember command names and type them. – user26112 Jun 20 '13 at 21:00
  • Automation and scripting works better in text-based environments I can say, but not everything done in the command-line couldn't be more conveniently done in a decor-friendly GUI with better organizing elements. – Lester Bonker Jun 20 '13 at 21:03
  • Well, think of it as a kind of "get your feet wet" kind of approach; minimally transfer only some of the features or commands that could be better expressed in graphic-layouts and leave commands that are easier to execute through simple character phrases for whatever convenience. I highly doubt though, as you said, that a graphical-program to teach Unix commands to new users would be automatically more easy than what I envisioned. The thing is, and I'm not the only one on to some of this: some, not all, but some features can definitely be better implemented with decor. – Lester Bonker Jun 20 '13 at 21:07
  • 2
    How useful would it be to have a button to list the files in a directory or list currently mounted filesystems? I wouldn't find it very useful. It's much easier to type mounts, which is an alias I have to mount | column -t... especially when there are dozens of other buttons. The table that command presents is useful enough for me. It may not be as "pretty" as a "modern" table, but I don't really care about that. There isn't much incentive for me to write a shell that displays a pretty version of that table. – user26112 Jun 20 '13 at 21:41

Written language is a sign of an advanced culture isn't it? Point and click is a regression.


I prefer the command line because it's faster, leaner, more flexible, and more powerful. Almost anything you can do with a mouse, I can do faster with a keyboard. It's the same reason I (and others) prefer vim to IDEs.

  • There's no evidence that you couldn't do it faster with a much more robust GUI with 3-D hardware accelerated features and a fast CPU compared with typing, whereas anyone can use a point-and-click or touch-screen features faster than manually punching in information in some cases. – Lester Bonker Jun 20 '13 at 20:47
  • Some ideas could be better diverted to GUI-implemented choices, such as list views with mount points (in Linux) or such. The resources used in a simple GUI window to better implement an easier to select and monitor table view of mount points would not necessarily show up in any constraints of real-time computing, processing power, or otherwise clock cycles, that would be anything worthy of complaining about. Point is, we're not using DOS anymore (well, not natively I can say for most of us, but I'm not denying emulation software), and like every OS got a make over, maybe the CLI needs one, too – Lester Bonker Jun 20 '13 at 20:59
  • I am not arguing with you on the subject of text editors to massive IDEs (like Visual Studio 2012), but in the sense of a light touch-up GUI resource constrained window, I doubt you'd find much, if any, visibly noticeable difference in executing a GUI-like environment with translated command-line commands to point-and-click or touch-screen configured buttons/etc. – Lester Bonker Jun 20 '13 at 21:02
  • 2
    Faster: By the time you figure out where the mouse is on the screen and moved it there, I've already got the command typed out. Now how are you going to add options or arguments? Either you'll have to have a horribly cluttered and clunky gui or you'll need to type them in somewhere. Guess what? I'm already there. – Kevin Jun 20 '13 at 21:59
  • 2
    And how do you propose to implement pipelines? I think your suggestion is shortsighted. It's possible that some pre-configured large command lines might be quicker to click than type (but make them an alias or function for equivalency and the command line is still faster), but the shell is too free-form. How do you propose implementing something like awk '/foo/{blah blah}' in a gui faster than with a keyboard? – Kevin Jun 20 '13 at 22:06

Some possible reasons:

  1. Scripts - automatization (as opposite to mouse and buttons) - so you don't waste your energy by moving mouse and clicking buttons manually every time.
  2. CLI is less distracting (concentration)
  3. CLI uses less resources (works faster)
  4. GUI is based on CLI (commands and files). You cannot get rid of CLI.
  • A CLI in modern computers is usually just an emulated console that the older OSes actually used on graphics hardware. Suffice it to say, there's nothing stating a GUI can't be faster and more efficient in terms of layout. Also, I would arguably deny that a CLI is automatically "less distracting" and that a GUI would ruin my concentration. In theory I would even bite and say that a GUI-based version of the CLI can be magnitudes more efficient than a CLI, which was more common twenty years ago. – Lester Bonker Jun 20 '13 at 20:50
  • 5
    @LesterBonker: In comments, we've given you several examples of actions that are straightforward on a command line but likely difficult or impossible in a GUI. You've asserted that GUIs can be more efficient, but you haven't addressed those examples. I have little doubt that GUIs could be made more efficient and flexible than they are now. I find it difficult to imagine how they can be made as easy for certain complex actions than CLIs. If know how to make GUIs work that well, you could become rich and/or famous. – Keith Thompson Jun 20 '13 at 22:31
  • 2
    @LesterBonker The assertion that a CLI is just an emulated console used on graphics hardware is factually untrue for most unices. And in fact, when I'm remote administering my servers I'm much more likely to use ssh than to fire up an entire remote desktop. – Shadur Oct 3 '15 at 20:26

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