I am a DBA fledgling with a lot of experience in programming.

I have developed several CLI, non interactive apps that solve some daily repetitive tasks or eliminate the human error from more complex albeit not so daily tasks. These tools are now part of our tool box.

I find CLI apps are great because you can include them in an automated workflow.

Also the Unix philosophy of doing a single thing but doing it well, and letting the output of a process be the input of another, is a great way of building a set of tools than would consolidate into an strategic advantage.

My boss recently commented that developing CLI tools is "backward", or constitutes a "regression".

I told him I disagreed, because most CLI tools that exist now are not legacy but live projects with improved versions being released all the time.

Is this kind of development considered "backwards" in the market?

Does it look bad on a rèsumè?

I also considered all solutions whether they are web or desktop, should have command line, non-interactive options. Some people consider this a waste of programming resources.

Is this goal a worthy one in a software project?

I also think that for a web or desktop app, having an alternate CLI interface is a great way of demonstrating that the business logic is completely decoupled from the GUI.

  • 32
    Does your boss come from a technical background? It sounds like he's following the "I don't see much, ergo there isn't much to it"-philosophy. Which can be problematic. Ask him if he thinks the people who develop Oracle are backwards as well. May 29, 2013 at 15:07
  • 13
    I like the way things are done in the Linux world. Most 'major' applications have both CLI and GUI fronts - this is libertaing because you can script when you need to and click with your mouse when you don't need to. I don't see why you necessarily need to pick one vs. the other. It does not take that much work to write a CLI.
    – MrFox
    May 29, 2013 at 19:21
  • 6
    Your boss obviously has never tried to write the most basic script May 29, 2013 at 19:46
  • 1
    @MrFox I agree with you, apps should have both front-ends. May 29, 2013 at 20:37
  • 4
    I like this but unfortunately there is also sometimes this ;)
    – wim
    May 30, 2013 at 3:51

7 Answers 7


Having the ability to work with a CLI is hardly what I would consider backwards. It looks great on a resume, especially if you can spin it on your resume with a phrase like "Used (Powershell/Bash) to build a suite of automation tools to send SMS messages when the Database was down".

When I am responsible for hiring people, a working knowledge of the CLI is something I look for.


It basically comes down to "use the right tool for the job."

If you have to interact with a user, you'll want some sort of GUI. We've got decades of research and experience showing that they make computing far more intuitive and productive. That's why GUIs have inexorably taken over the world ever since 1984: they just work better for interacting with people.

But if you're automating a program with scripts, your program isn't interacting with people; it's interacting with a script. And the best interface for that is a text-based one, for reasons that should be intuitively obvious.

The development of CLI programs for users to work with directly is considered backward, and with good reason. But if that's not what you're doing, if you're writing automation productivity tools, then you aren't doing anything wrong by giving them a CLI.

  • 6
    +1 Well some of the tools give information to users, like "are all database backups up-to-date, if not, tell me which ones are old ?". They print the answer to STDOUT. But obviously it can be put on a crontab in order to send a SMS if the answer is NO. I think even if the app is GUI, it should have a CLI mode with parameters. I myself am an admirer of GUIs, I'm a Mac user after all. Many business critical apps, specially the ones developed in-house never contemplate a CLI. May 29, 2013 at 15:17
  • 23
    While I 99% agree, I have also found that, as a technical user, sometimes I prefer the CLI to a GUI. The reason is because many GUIs require me to navigate, point, click, go through menus, search for the right check box, etc. However on a CLI, all I have to do is translate the English in my head to "Computerish" on the command line, and the program does what I want in less time. So while GUIs are much easier for casual users, hardcore power users sometimes prefer the CLI.
    – Phil
    May 29, 2013 at 22:18
  • 15
    "The development of CLI programs for users to work with directly is considered backward, and with good reason" um, no, its not that simple, hence why any sufficiently advanced GUI app end up embedding some scripting engine with its own CLI
    – jk.
    May 29, 2013 at 22:21
  • 11
    @MasonWheeler: I think you're missing jk.'s point. When a GUI becomes complicated, tech-savvy users will often prefer to use a CLI scripting engine even for a one-off task. Which absolutely is "users working with [it] directly".
    – ruakh
    May 29, 2013 at 23:14
  • 8
    -1 on "the development of CLI programs for users to work with directly is considered backward, and with good reason" this totally depends on the application. Many times as a user I need to work with a program to run on a machine which doesn't even have a GUI or a monitor. I sure as hell need a CLI then!
    – wim
    May 30, 2013 at 3:57

Eric Raymond's The Art of Unix Programming is the canonical work for the argument you're making. I won't try to condense his excellent book into a couple paragraphs. However, keep in mind that argument applies mostly to programmers, administrators automating tasks using scripting, or power users of highly technical software like CAD.

Even with highly technical users, you have to consider which hats they are wearing at the time. For example, I write embedded software for networking equipment for a living. Our products all have both a CLI and a GUI, but developers almost universally prefer the CLI, due to its flexibility, scriptability, availability, speed, etc.

However, that exact same group of developers overwhelmingly prefers the GUI on our version control software, even though its CLI is more powerful and is supported and documented just as well as the GUI. The difference is we are the end users of the version control software, not administrators or developers.

So carefully consider what roles your users are in when they're using your utilities, and plan the user interface accordingly. If your boss is mentioning it, chances are you need to improve the documentation and/or training on the CLI at the very least. If you're constantly telling people a feature is only available on the CLI when they expect it for the GUI, you probably need to rethink your development priorities, taking the needs of your users better into account.


It's not just Unix that's driven by command line programs. Microsoft is heading that way too.

Microsoft has been pushing PowerShell for some time now. All of their current server software (Exchange, SharePoint, Server 2012, System Center, etc) can be completely controlled through the PowerShell command line. And PowerShell relies on small functions that do one thing well and pipe data to the next one (though it pipes objects instead of just text).

Most of the GUIs to those programs are simply a frontend to the PowerShell commands, many even tell you what commands it's going to run to make scripting easier. Everything you can do from the GUI you can do from PowerShell. The reverse is not true - there are quite a few functions that are exposed only in PowerShell.

So if *nix has always done it, and Microsoft is heading that way... doesn't seem very backwards to me!

  • 5
    Just to add to this: Microsoft pushing away from the GUI on servers in a big way. They want everyone running Server Core - no GUI, period. If you can script a set of tasks on one machine, you can script it across the whole enterprise - good luck doing that with a GUI. Jeffrey Snover (lead architecht for Windows) gave a good interview on the topic.
    – alroc
    May 29, 2013 at 20:46
  • 4
    "Windows" is not heading that way; Windows Server is. A server is meant to run as an automated system with minimal human interaction, so that makes sense. But you're never going to see that happen on the user-facing parts of the OS. May 29, 2013 at 20:52
  • 3
    Also, Mac OS X switched from a pure GUI to a *nix architecture with a strong focus on command-line scripting. Therefore, I would say that both Microsoft and Apple have been heading towards more CLI.
    – Brandon
    May 30, 2013 at 0:53
  • 1
    +1 I had to explain to C level folks how 'Windows' was going back to text. It makes sense - every action can be scripted,tested and rolled out to thousands of servers rather than logging in to each box and trying to accurately replicate 200 mouse clicks. The OP should pitch his/her skills as scripting/automation rather than just as CLI. IIRC Windows offers powershell support from XP onwards. It's great to install pre-reqs by one script instead of a lots of clicking.
    – jqa
    Jun 1, 2013 at 0:15
  • You're right, but keep in mind that for the masses of (stupid) computer users, GUIs will be the only thing they know and see... this is especially true if you consider the fact that the GUI is older than a lot of them... Jun 26, 2013 at 9:06

I would definitely not say it's a bad thing. The nice thing about CLI programs is that when implementing them you can have a very restricted scope. For instance, if I want to write a cat clone or "a program to print the contents of a file to the screen", that's very feasible with CLI.

However, what if you didn't use CLI, well then you'd have a basic program with a GUI that displayed some text. But then you'd also have to tie in opening a file dialog and hooking that up.. but then someone also wants to be able to modify the text and save it elsewhere..

Scope creep is ridiculous with GUI apps. It's so extremely easy to avoid though with CLI apps. "You want to edit the file and then resave it? cat foo > ed > bar" With CLI apps it's trivial for your users (not you, the developer) to combine it with other tools.

Now, that being said, CLI programs are starting to be viewed as "backwards". This is because a lot of application development these days happens in marketplaces where users combining your tool with other tools is next to impossible. I won't go into that here, but I did write a blog post about how "marketplaces enforce master-of-none mentality", which is the complete opposite of a well designed CLI app (to do one thing and to do it well)


The GUI and CLI both have their place. The GUI is great for allowing a user to perform certain canned operations quickly. The CLI is for when you want to do things the GUI doesn't allow you to do. The CLI is usually more powerful and harder to use.

A good CLI tool allows the user to do things the person who wrote the tool never thought of. One example is the UNIX 'find' command. This command:

find . -type f -name xyzzy\* -maxdepth 5 -mtime +3 -exec rm {} \;

finds files under the current directory (but limited to 5 levels down) that have a name starting 'xyzzy' and were modified more than 3 days ago and then delete them (note: untested code). And that's a moderately simple usage. You can use a file manager to do that sort of thing, but it will take longer and is error prone. Of course, being more powerful means the CLI can be more easily misused and create problems for yourself!

A good developer might write a CLI tool in such a way that it also has a GUI allowing a limited set of operations to be performed. The user can start with the GUI and learn the complexities of the CLI later.

A good (long and biased (?)) read on the CLI/GUI tradeoff is at:

  • 1
    +1, especially for the reference to "In the Beginning was the Command Line"
    – Ben Lee
    Jun 4, 2013 at 0:43

No, it's not backwards at all.

The "direction" has a lot to do with our perspective. A user happy with the current path toward simple, "one experience all devices" interfaces is going to see the CLI as a throwback or regression for sure. It's not in line with their overall expectations.

A programmer, administrator or power user may well see it as the logical progression of tools according to their experience. Many of these start out using GUI tools. When they want to or need to scale, they rapidly figure out why the CLI exists and that progression resonates with those building more CLI tools.

There is this by Paul Ferris: http://www.linuxplanet.com/linuxplanet/opinions/1505/1

To me personally, the idea of syntax differentiates the two. When syntax is somewhat present in a GUI, the result is almost never good and as flexible as well thought out CLI syntax. When this is coupled with pipes and redirection, the GUI falls flat due to it not being very useful outside the planned use cases.

My personal preference on this is CLI tools that offer a --gui or --verbose option sufficient to allow a GUI wrapper to interact in a robust way including status bars and other basic elements people look to the GUI for.

Of course the cost of this is essentially two programs with one rather useless without the other, but the major benefit is being able to incorporate one or more great CLI tools into a custom GUI without modification to said CLI tools. Most often this is only done to offer a GUI option on a particular CLI, but the idea of driving multiple tools with one "process" or "use case" oriented GUI can deliver results similar to piping and redirecting and scripting for that use case, making it available to people who would not perform those operations regularly enough to reach mastery while still not inhibiting the CLI users.

I encountered this approach on SGI IRIX and really liked it. I found myself using either the GUI or command line as needed and the nice thing was knowing exactly what the fancy buttons were actually doing.

Where there are lots of different operating environments, the GUI wrappers can differ considerably without impacting the CLI tool as well.

I see this in Linux today with things like disk / filesystem tools, where the GUI can add a lot of value even to CLI familiar users.

In the case of known filesystems / disks / devices, knocking out the CLI isn't tough, and it can be scripted of course. Mistakes can be painful however.

Where those may not be known, or perhaps performing the operations isn't done regularly enough to remain solid and error free, running the GUI provides an environment that can be easily verified, operations chained together and then run with confidence, no scripts required.

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