Five years ago I wrote a little blurb called Death of the command line. As it happened, that article was misunderstood by many who read it - I don't know if it was my fault or theirs, but somehow many readers ended up thinking I was either predicting the demise of CLI's (Command Line Interfaces) or hoping for that demise or both.

Nothing could have been farther from the truth. I remain a big fan of CLI's and use them daily. And yet, just five years later and still at risk of angering yet another batch of folk who won't read carefully, I'm going to suggest that predicting the death of the CLI may not be such a bad bet after all.

What triggered this was that I happened to be doing a bit of editing to another article - Using the shell (Terminal) in Mac OS X. As I made some corrections, I thought "Nobody cares about this nowadays".

That's not entirely true. That particular page still gets five thousand or more visitors every month and has even been "plussed" a few times, so obviously a few people still care. On the other hand, in the greater world of folks I run into daily, nobody uses the CLI and most don't even know that they could.

But why would you use the CLI?

That's the kind of question that makes people like me sputter a bit. "Because it's faster!", we exclaim. "Because you can do things that you can't even do in the GUI!", we add (GUI: Graphical User Interface).

That is so much faster than clicking numbers on a GUI calculator, I'd say, and I'd add that actually, it's even faster, because I leave "bc" running in a Terminal tab on my Mac.

But.. it really isn't faster. In fact, if I already have Calculator up and running, I can switch to that and type exactly the same keystrokes, minus the spaces, and get an answer just as quickly. So "faster" doesn't really hold true.

Ahh, but what about cut and paste? There's the rub - you can't highlight a number in Calculator and copy it to paste it elsewhere!

Well, that's this particular calculator and actually, it will let you copy and paste results - it just dispenses with any need to select them with your mouse. Just use the Copy in the Edit menu or the command line equivalent and it's done.

Bad example?

Maybe that was a bad example? Sure, I can come up with specific things that are faster in the shell, but the problem is that all of them are somewhat esoteric or special case. They are either things that you'd seldom or never do or things that you COULD easily do in the GUI if you arranged things ahead of time to make the task easier.

As a proponent of CLI, I'd argue that the flexibility is an important point: the CLI lets me quickly do things I did not know I was going to need to do. That's true,but do those situations come up often enough to make it worth while for the non-shell savvy user to learn all that they'd need to learn? After all, those unusual situations usually require more than a casual knowledge of shell commands and scripting - there's a learning curve that just might not be worth the effort to climb!

Wild cards

I and anyone else defending CLI's will often invoke wildcards as an example of CLI power. With judicious use of wildcards, you can accomplish things very quickly that could definitely take much longer in the GUI.

However, most examples I could give would be contrived, esoteric or incomplete. Are your or I likely to need to copy or remove files that match "*[6-9]+.*" while avoiding all others? Sure, very rarely such needs do come up and the GUI user is stuck with laborious work that requires only seconds for me to accomplish. But really, how often is that? Is it often enough to justify that learning curve? Even I don't think it would be and if I didn't already have the knowledge, I might not bother to obtain it!

The other part of this is the "incomplete". When I do find myself needing esoteric wildcards, it's the copying or removing is only one part of a bigger project, and that larger need usually involves much more difficult scripting or even - gasp - real programming. Again, that type of work is not something most people ever do.

Is there really any reason to learn CLI?

I'm reminded of my own efforts to learn Spanish. I'd like to learn it, and I have made some efforts in that direction, but I don't have any real need to do so. Like the examples of shell commands I gave above, knowing some Spanish could come in handy now and then, but I have no strong reason to climb that particular ramp. I lack incentive other than intellectual curiosity.

For most computer users, learning shell commands or, even worse, shell scripting, fails to provide enough tangible reward to pay for the time and effort involved. Believe me, it bothers me greatly to say that. Emotionally, I rebel against that thought: it can't be true, it must not be true!

Yet it almost certainly is true.

Please, please, please tell me that I am wrong. Demonstrate the flaws in my logic, show me the errors of my ways. Convince me that my emotional response is the right one; show me why computer users should learn command line basics.

You might convince me, but I have real doubts that you can. As to convincing the millions upon millions of those who have never used a shell at all, I'll bet even the most adamant of shell proselytizers will admit defeat on that challenge.

Given this apparent truth, will tools like Mac OS X Terminal and Linux Konsole slowly get hidden away much as the programmer tools are now? Will they require a special installation? Honestly, if Apple did that, it wouldn't surprise me at all. I'd expect Linux to resist de-shelling quite a bit longer, but even there the CLI may drift into insignificance.

The average user can get by without a CLI or scripting. They can, and do, get by without learning the most elemental keyboard shortcuts that would save them 2-3 hours per week processing mail, writing documents, filling in forms, etc. There are 2 kinds of users - those who are happy with their limited knowledge, and those that want to do things better.

Here are some things I do regularly via scripting that saves me hours and hours of time. I record myself playing music, copy the files onto computer. Rename the generic soundfile names to something human recognizable, and update the ID3 tag so that the artist, song, and album show up in an mp3 player. Sure, I could go into the Windows Explorer, right click on the file to change the name, and find some software to update the id3 tag - but that would take forever. I wrote a simple shell script that plays everyfile, takes my input to rename the file, and automatically numbers them. I have another script that uses the file name and directory structure to write song/album/artist into the ID3 tag automatically. I have another program that will read the EXIM data in a photo and rename the JPG to a name that includes that date/time and organizes the picture into a YYYY/MM directory structure - that's the way I like to store my pictures.

I couldn't even calculate how many hours these things have saved me. I will use the CL to adjust the volume in a directory full of MP3 files, or batch convert mpgs to mp3s so I can listen to them in my car. I could go on and on describing little utilities, scripts, and commands that save me massive amounts of time. But that's me. I HATE doing repetitive tasks. Most users are happy to just get the job done - even if it takes them 100 or 1000 times longer. If you had a directory with 10,000 photes 1.jpg, 2.jpg, ... 100000.jpg and wanted to rename them according to date/time - how long would it take? It takes me like 2 seconds.

The average user may not need a CLI - but some of us do, and always will need it.

Thu Sep 8 01:41:52 2011: 9779 TonyLawrence

But if you had never learned anything about shell scripting, would you (a generic you, not the real you) had even realized that you could do that and if you did, would it seem compelling enough to make the effort to learn?

Thu Sep 8 02:28:31 2011: 9782 wolfhalton

Faster for repetitive things. Rename 2 files, not obviously faster. Rename 180 files, oh yeah - much faster. I use the command line for hours every day because it is the fastest way to administer a linux network.

Thu Sep 8 02:54:16 2011: 9783 Mark

Before I ever used unix or had any real computer training I used DOS something or other and wrote batch scripts to help me do things more efficiently.

Before all of that we used Data General Nova computers that ran our testers and they had this thing called a command buffer - you could load a series of commands into the buffer and recall them. If I was testing Board-X - I had buffers that ran all the checkers for that particular board and printed out the summary so I could bench test boards while running others in the system. The other techs sat there in front of the system drinking coffee and reading the paper waiting for the current checker to finish so they could type in "load whatever.ck .. run .. run"

Back to my example of people who won't even take 5 minutes to learn keyboard shortcuts in their everyday-applications - shortcuts that would save them hours and hours and hours. Sure not everybody is going to learn perl, php, etc. But plenty would break out the command line to solve some problem if the google results told them to.

Thu Sep 8 02:54:16 2011: 9783 Mark

Before I ever used unix or had any real computer training I used DOS something or other and wrote batch scripts to help me do things more efficiently.

Before all of that we used Data General Nova computers that ran our testers and they had this thing called a command buffer - you could load a series of commands into the buffer and recall them. If I was testing Board-X - I had buffers that ran all the checkers for that particular board and printed out the summary so I could bench test boards while running others in the system. The other techs sat there in front of the system drinking coffee and reading the paper waiting for the current checker to finish so they could type in "load whatever.ck .. run .. run"

Back to my example of people who won't even take 5 minutes to learn keyboard shortcuts in their everyday-applications - shortcuts that would save them hours and hours and hours. Sure not everybody is going to learn perl, php, etc. But plenty would break out the command line to solve some problem if the google results told them to.

Thu Sep 8 12:53:14 2011: 9787 BigDumbDinosaur

The command line will never die as long as people like me are around to work on computers. GUI is for the clueless user who hasn't...er...a clue about computers. They are operating the computer in the same sense as using a toaster. When something needs adjusting, fixing, cleaning or tightening on a system, I usually reach for the command line, even in Windows.

As for learning scripting and all that, if you need it you'll learn it.

Thu Sep 8 19:57:38 2011: 9793 MAXIMUSIRILIOUS

I agree well said CLI i believe is just easier to use in a sense instead of getting some third-party software
to do it for you clueless-ly. (more time wasted)

Thu Sep 8 21:10:44 2011: 9794 AndrewSmallshaw

The command line will never disappear. It's strength is both depth and breadth - a rarely used command doesn't clutter up the place until it is actually needed. At a shell prompt on this system here I have 3,335 commands at my disposal, ready for use simply by typing in their names. A GUI that presented that many alternatives would be unweildy, even when a hierarchy of some sort is used.

If you want evidence of that look at the run box on Windows. It used to be on a dialog box of its own. On recent versions it is right there directly on the Start menu. What is that if not a simple command line? Why is it there except because it has been recognised that several hundred items on the Start menu are difficult to handle, even when divided into separate folders.

The calculator example is also a very good one of the strength of the CLI. Yes, it's one thing that you might want to access quickly, but there are countless others: I may want to look up a word in a dictionary, or check the date a week of Wednesday. The usual random example is of course the phase of the Moon but as an amateur astromoner that isn't unrealistic. If the idea is you simply have the relevant windows open just in case that doesn't scale: you end up with too many windows open and when you actually do you then need to find the right one. At the command line those examples are "bc" or "dc", "dict", "cal" and "pom", and they can be completely ignored until needed.

More evidence is when you consider apps that are inherently complex: for example how many high-end CAD programs are there out there that do not prominently feature a command line? GUIs work fine when at any one time you are 99% likely to need one of perhaps a dozen options that can be presented to you easily. When the active set of possibilities extend into the hundreds they fail to scale.

This is without even considering the ability to chain command line tools together to achieve novel results. Where did that 3,335 figure above come from? Not one of those tools does that. It is a trivial matter to assemble a commmand to work it out though:

n1c$ IFS=:
n1c$ for i in $PATH
> do
> ls $i
> done|wc -l
3335

You can call that scripting or even programming if you want. In reality is is simply using the facilities that are available.

Fri Sep 9 07:46:17 2011: 9795 Vonskippy

I just setup a entire LAMP stack on a remote server. Nothing but SSH and a slow 1M connection between me and it. Lets see someone use a GUI (via VNC) and get the whole process (including 8 vhosts) done in less then an hour (including a complete config backup and a automated nightly content backup to dropbox).

For servers - a GUI is just a waste of time, system resources, and space.

Sat Sep 10 11:45:55 2011: 9803 TonyLawrence

I think what most are missing here might be illustrated by "telnet" in Linux distributions. It's *available* but not installed by default.

You can see the same thing with Apple's development tools - free, easy to get, but not installed by default because although I and many others WILL install them, most users do not and will not miss them.

My feeling is that we could expect this distancing to happen to Terminal in Mac and Linux in coming years.