APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Death of the command line

© Anthony Lawrence, aplawrence.com

It's hard for me to imagine using an OS without a strong command line. Even Microsoft has recognized the for that with their Monad Shell ( though they are at least temporarily removing that from Vista). Linux of course has its Bash shell, Mac OS X has Terminal (which now defaults to Bash) - everybody knows you need a shell.

But who really uses it? Well, I do, and maybe you do, but most Windows users certainly don't, and most Mac users are equally command line phobic. Linux users may be a bit more apt to drop into typing-land, but even there it's being pushed into insignificance.

For example, I recently installed a Suse 10.1 system. I needed to add some printers, but I couldn't remember the syntax for adding an smb printer with lpadmin - it's just "lpadmin -p printer -v smb://host/printer" but I was having a senior moment. I was sshed in at a command line and what I wanted was something like "redhat-config-printer" to help me through it. If there is such a thing in Suse, I couldn't find it.

I was able to get by this by installing Lynx (yast2 --install lynx) and running "lynx http://localhost:631" to get the Cups browser interface (though I first had to add a cups user with "lppasswd -a root"). That's fine; I was able to do what I wanted, but I'm pretty sure most people would have given up and used the GUI.

We old command line hands know all the arguments for the importance of the command line. We can build tools on demand with pipes. Therefore we can do exactly what we want quickly and efficiently. GUI tools often have less features and can't be piped to other GUI tools.

Yeah, but.. They could: Nothing stops a GUI tool from implementing all the features of its command line equivalent. And there's no reason that a GUI application couldn't pass or accept data from some other GUI application. If all applications were written with that ability, you could just string things together. In fact, some graphical programming environments work just like that: you drag around little tools and create bigger tools without suffering the indignities of that awful command line.

If every GUI app could read standard input (and actually many do) and had an option to send text output to any other tool, we'd have the same power in the GUI. You'd need a master pipe fitting app to build reususable tools, and of course the tools themselves would need to accept behaviour changing arguments, but none of that is difficult.

Would this be better than the command line? Worse?

Added after the original post to avoid more misunderstanding:

I'm not a "point and click" fan. I LIKE CLI's for their power, speed and convenience. My fear is that developers are neglecting CLI tools in favor of GUI versions.

See Lessons learned from Digg also.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> Death of the command line


More Articles by

Find me on Google+

Anthony Lawrence

Click here to add your comments
- no registration needed!

Sun Jul 30 15:00:18 2006: 2302   BigDumbDinosaur

Nothing stops a GUI tool from implementing all the features of its command line equivalent.

Except it would be less efficient. If the task involves repetitive steps, the overhead imposed by working within the GUI tool (and the much bulkier code associated with it) will reduce execution speed. The closer one is to the OS the fewer steps that need to be taken to do something. I can foresee where loops would execute slowly.

If every GUI app could read standard input (and actually many do) and had an option to send text output to any other tool, we'd have the same power in the GUI. You'd need a master pipe fitting app to build reususable tools, and of course the tools themselves would need to accept behaviour changing arguments, but none of that is difficult.

Would this be better than the command line? Worse?

Worse, in my opinion. It's hard to generalize anything in GUI, easy in BASH, KSH, etc. My guess is that a purely GUI-driven environment such as you describe would be bulky, unwieldy, cumbersome, slow, elephantine...did I miss any adjectives? <Smile> Also, what do you do if the GUI code is broken?

Sun Jul 30 17:40:50 2006: 2304   anonymous

This idea already exists. On a Mac there is a piece of built in software called Automator. You can chain together several tasks (using many different apps) to form a 'workflow', it's really very sweet... and all GUI

Sun Jul 30 17:42:51 2006: 2305   anonymous

Nothing is stopping GUI programs from acting like filters, but it's much faster to build a pipeline in the shell than it would be by dragging programs around. Of course, there may be a better way that no one has found yet, but until someone comes up with a graphical way that is at least as efficient as typing, I will continue to use the shell.

Sun Jul 30 17:44:02 2006: 2306   anonymous

The mouse is far slower than the keyboard. The type of users that don't use the command line are the type of users that don't use keyboard shortcuts. Sure, having the GUI program set up to send its output to another program is faster than, say, copy/cut and paste. However, there is no way that a GUI can replace a CLI for any CLI user. This has to do with the efficiency of the keyboard over the mouse. If you set up the GUI program to be ran by hotkeys, then honestly, what's the difference? Sure, one wouldn't be using the CLI any longer. But the average user will STILL not want to learn it because they will have to memorize hotkeys. I don't believe the CLI will ever be made obsolete.

Sun Jul 30 17:49:16 2006: 2307   anonymous

So....Apple's Automator?

Sun Jul 30 17:53:10 2006: 2308   anonymous


It'd be slower to use, slower to run, harder to document and as different GUI apps are built in significantly different ways using differents frameworks/APIs on different desktop environments & window managers.

Oh and by the way, next time you have a senior moment remember you can run SUSE's Yast in CLI too

Sun Jul 30 18:21:08 2006: 2309   anonymous

Take a look at the Konstanz Information Miner; it runs on Linux or Windows and comes with source: (link)
Also, Pipeline Pilot. (Very expensive and marketed to chemical/drug companies): (link)

Sun Jul 30 18:44:03 2006: 2310   anonymous

I use the command line because it's faster for me. If I want a text editor I just start typing 'emacs' instead of going through a menu and hoping that abiword is still called abiword and not gnome word processor. Basically I get what I want with the command line, but I have to go searching with a gui. If I'm not familiar with something enough to know exactly what I want, I have an easier time discovering what's available in a gui.

Sun Jul 30 18:58:33 2006: 2311   anonymous

Currently working on a Spyware-infested PC. It has disabled the Wondows Taskbar and not icons available on the desktop. Were it not for the CLI, I'd have no way to run diagnotic tools at all.

Sun Jul 30 19:35:01 2006: 2312   anonymous

I don't think a mouse, buttons and drop down boxes can ever fully replace the command line. As a Windows and Linux sysadmin, there are certain things that simply have to be done via the command shell. Imagine what it would be like trying to maintain an Apache server over a slow WAN link without being able to use the shell.

I once had an Exchange database (about 35GB) dump on a production server. The ONLY way to repair the database was by using the command shell. Also, even in the Microsoft world, any truly advanced functionality for working with, or reapiring an Active Directory require the use of the very opaque utility called ntdsutil.

Perhaps a Desktop machine can be run easily enough without a command shell, but anyone who claims to be a sysadmin but is scared of seeing either "user@host:~#" or "C:\" may want to consider an alternative career path.

Even with a gui as nice as OSX, I still have yet to figure out how to change the system's root - root, NOT the admin user - password without pulling up a terminal and typing in: sudo passwd root

Shells aren't dead - and I doubt they will be dead anytime soon.

Sun Jul 30 19:48:11 2006: 2313   TonyLawrence

Well, to my mind, automator is pretty sad: (link)

But, yeah, that's the idea.

I'm glad to see so many people defending the command line..

Sun Jul 30 19:59:29 2006: 2314   TonyLawrence

Gosh, so many people misunderstood this terribly. My fault - I wasn't clear enough.

I'm NOT anti CLI. If anything, I'm more anti GUI. I spend most of my time in the shell and have since I first started wth Unix (circa 1981).

And the article point wasn't "Gee, I wish I had a GUI". Quite the opposite in fact: my fear is that cli interfaces are being neglected in favor of GUI's .

Try re-reading it fwith that in mind.

Sun Jul 30 20:12:37 2006: 2315   anonymous

I'm not sure if anyone uses SPSS, the statistics package, but I use it and it combines a GUI with command line syntax. I find both work very well together.

When you do anything with the GUI in SPSS every action is recorded in a text log. If you want, and I do, you can look at the log and copy and paste the syntax to do repetitive tasks quicker via command line.

Why not just use the command line syntax from the beginning? Well, because I'm not psychic and I don't want to spend an hour figuring out the text commands. It takes 30 seconds to do it with the GUI. Once I make sure it works, I look at the syntax and all subsequent tasks I usually do with the command line and it takes 5 seconds. This means the GUI and command line _complement_ eachother.

Sun Jul 30 20:24:40 2006: 2316   anonymous

Just want to plug autohotkey - a windows freeware automation tool www.autohotkey.com/ (link dead, sorry)

I've used this to automate GUI-only software so that I can run it and glue it to other applications. Like software that can only backup via GUI.

IMHO GUIs are only really useful in medium complex environments. As soon as you want to do something really complex, command line arguments are suddenly faster again.

Sun Jul 30 20:33:13 2006: 2317   anonymous

I believe BeOS had something like that where all apps could be controlled from the command line. Also there is VB Scripts for Windows, but the documentation is less then steller.

Sun Jul 30 21:55:35 2006: 2318   jan

It is basically a graphical command line. It has a GUI that is as fast as the commandline and it lets you do virtually anything on OSX. If you are really into it, for any given task you think: "Lets fire up Quicksilver and see how we get there." - Seconds later you're done.

Moral: The commandline in the form of a terminal might be on a decline, but the general concepts are too powerful to be overlooked.

As a developer, I spend 20-40% of my time on a good ol' terminal and I don't see that becoming less.


Sun Jul 30 21:58:00 2006: 2319   anonymous

Apple is way ahead of you with AppleScript and Automator. Check out the video www.apple.com/macosx/features/automator/ (link dead, sorry) It's not quite stdio piping, as there is type checking, but it is a GUI to quickly making your own tools.

Sun Jul 30 22:01:21 2006: 2320   TonyLawrence

I wish people would bother to read EVERYONE's comments before they throw in their two cents..

Sun Jul 30 22:23:08 2006: 2321   anonymous

I have never seen REXX running, but it is the earliest I know of automating apps outside the CLI (1980s)... I dont know if they were GUI apps. Shortly after REXX the Amiga had AREXX (1991?) which used its multitasking abilities to autoate GUI programs and for the GUI programs to comunicate. Be OS which was created by Mac and Amiga programmers had something similar.

This is a great idea, but not a new one. It has taken Apple a surprisingly long time to copy the Amigas abilities, and they still havent pumped this old well dry yet.

Mon Jul 31 04:22:49 2006: 2322   drag

A scriptable GUI is a horrible idea.

I've TRIED to use Apple script and was very irritated. It took me hours to do on a GUI what I could accomplish trivially easily on a command line.

What I like more is that for applications...

A GUI written in a high level language. Like python or C#. The reason is that the GUI needs to be adaptable and bug free as possible. A higher level language means that it's more quickly programmed, less likely to have odd bugs, and more easily adapted. (of course correctly programmed.) Speed is very very secondary. The app would be waiting far more often on the user then other way around and if programmed well the difference should be unnoticable.

The core portions of the application, were the real work gets done, should be in optimized libraries and utilities. Stuff that should be accessable more directly from the command line.

That way you end up with the best of both worlds. Something that easily scriptable, but for daily stuff and for non-technical users the functionality is aviable from a friendly GUI.

This is one of the things that I think that Linux does better then OS X. With Linux it is very common for programmers to take advantage of proven command line programs (like cdparanioa utility for a GUI cdrom ripping/encoding program) and use their existing functionality in their programs. It could be better, of course.

With OS X the 'Aqua' portion and the 'BSD' portion exist in their own little worlds. They both see the file system differently. (like "volumename:directory:filename" vs "/directory/filename". How does a mount point get displayed in finder? Last time I tried it mounting something from the command line locked finder up good, but that was a while ago.

I think the ideal situation is to have both closely tied together. A fully interactive environment were you have a sophisticated command line that GUI can respond to and visa versa.

Thu Nov 30 02:37:34 2006: 2669   anonymous

Automater isn't the answer, Quicksilver is

Thu Nov 30 02:43:09 2006: 2670   Tony

Well, for me Quicksilver is an answer to a question I didn't ask:


Sat Dec 16 20:55:58 2006: 2754   blackbeltjones

I can only speak for Linux, but there's about zero chance of the command line dying in Linux. If the chats and forums I frequent are any indication, it's still wildly poular as an interface among the real enthusiasts, who, after all, are the people who develop Linux, but even more important than that may be the fact that many if not most central Linux GUI apps are actually front ends for command line applications.

People need to get through their heads that the command line and the gui are not in competition. Terminal windows like Konsole and Gnome-terminal integrate the command line into the desktop, allowing the user to choose what interface he or she prefers from task to task and from moment to moment, according to the user's ability, inclination, or whether or whether the user is sitting up or lying down. (Yes, I do take my computer to bed with me. Yes, I am a lonely guy.)

Konqueror actually allows me to combine the gui and cli in very direct and intereresting ways. I only discovered that recently.

Of course, most of the development these days goes on in the gui, and that's entirely appropriate because that's where it's needed more. The gnu command line applications are often based on Unix commnad line applications that have been around for thrity years or more. They're reasonably mature.

I have been descibed as a "Command Line Freak", although I came to Linux four years ago from a non-technical background and I'm hardly an expert. I absolutely favor the development of easy, powerful gui tools. They will bring users to Linux, and Linux will bring users to the command line. The command line is not nearly as hard to learn as people think. Everybody should know how to use the command line, but no one should have to.

(link dead, sorry)

Sun Dec 17 09:10:49 2006: 2757   drag

if you want to check out a effort to make a user friendly command shell.

Check out fish...

Sun Dec 17 12:14:39 2006: 2758   TonyLawrence

I had looked at fish a while back
( (link) )..
kind of forgot about it til you mentioned it.

Sun Dec 17 15:50:45 2006: 2759   BigDumbDinosaur

(Yes, I do take my computer to bed with me. Yes, I am a lonely guy.)

Sounds like a topic for a Dr. Phil show. <Grin> Computers are great but cannot replace the companionship of a sexy and intelligent woman. Yuh need to get a life, boy!

Mon May 5 00:36:31 2008: 4169   anonymous

Blech. I disagree with this article. Anyoen who suggests a CLI is dying obviously doesn't use UNIX or Linux very much. CLI use in *nixes are immensely in depth.

Though this article smells of Mac OS X user. It likes to say it is UNIX, but it is an embarrassment of a UNIX. One which doesnt really do much of anything like UNIX.

Mon May 5 09:52:08 2008: 4170   TonyLawrence

Anyoen who suggests a CLI is dying obviously doesn't use UNIX or Linux very much.

Anyone who could read this and come to that conclusion obviously can't read.

Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments

If you want a picture to show with your comment, go get a Gravatar
Kerio Samepage

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

I am a Kerio reseller. Articles here related to Kerio products reflect my honest opinion, but I do have an obvious interest in selling those products also.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.

This post tagged: