Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

What benefits are gained from using the command line for software development over using an alternative GUI? Is the command line faster for certain tasks? Are certain tools only available via the command line?

share|improve this question

closed as not constructive by Jim G., Kilian Foth, Walter, Yusubov, Dynamic May 28 '13 at 19: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.

Do you mean using command line compilers versus an IDE? Or are you talking about UI of the programs you create? – Lord Tydus Sep 30 '12 at 14:39
@LordTydus I was referring to command line compilers and other command line tools and how it can be used to manage databases etc vs an IDE ad other GUI tools – br3w5 Sep 30 '12 at 14:47
By the time Eclipse is able to display its splash screen, a CLI master has launched vi on a file, fixed a minor bug and saved the updated file. Maybe make is in progress as well. – mouviciel Oct 1 '12 at 7:02
We wont mention what happens when the UI guy remotely shells into broken machine halfway across the world.... The cli guy is down at the pub for Friday afternoon drinks before the splash screen is loaded..... – mattnz May 23 '13 at 8:31

3 Answers 3

up vote 25 down vote accepted

Advantages of the command line over GUI applications include:

  1. If you are writing such tools rather than using them, the command line is easy to develop for. Accepting arguments on the command line is trivial and outputing to a text stream is similarly easy.
  2. Command line applications can easily be used in batch files or scripts, which is great for automated testing or builds. Most build tools, like make, ant and msbuild provide good support for calling command line tools.
  3. The input, output and error streams can easily be redirected, allowing information to be sent or received from files or other applications. This can mean test data can be easily supplied or output captured.
  4. There is a simple but standard error return mechanism (return code and the error stream). Detecting an error in a GUI may require UI automation.
  5. Use over remote shell or similar connections makes it much easier to perform tasks remotely, such as when a developer is connecting from home or on the road. Remote desktop connections are more prevalent these days but require more bandwidth and a lower latency connection.
  6. There are defined standards for help (such as the unix man command or passing -? as an argument). If someone does not know a feature, they can easily see what the tool provides. Similarly, there are defined wildcard syntax standards for specifying multiple files, drawing on likely existing developer knowledge.

However, command line applications have these disadvantages compared to GUI applications:

  1. Command line applications are harder to learn to use, particularly for those not used to them. This is usually not a problem for software development because developers are often used to command line tools but could be problematic for less technical people involved in development such as junior QA, localization and technical writers.
  2. Command line applications require a keyboard and so are impractical for some devices like phones or tablets.
share|improve this answer
thanks for such a comprehensive answer (i'll let the question mature a bit then select a chosen answer but yours is very helpful) - are there any resources you would recommend for gaining a thorough knowledge of the command line (preferably linux terminal)? – br3w5 Sep 30 '12 at 14:19
@ssbrewster The art of unix programming ( will give you a good idea of why the linux command line works the way it does. Which is much more important for learning to use it than how it works. The important thing to know is what the underlaying conventions are and how to discover new functionality. Once you know those two things, everything else will unfold naturally with time. Also, it's a damn good read. – Racheet May 23 '13 at 8:58

I assume you mean using a command-line compiler instead of an IDE. Leave a comment if not and I'll delete my answer.

Learning. Learning how units of code are compiled, linked, or mapped together in your language. Typically you must explicitly tell the compiler which files to compile and link. So you gain a better understanding how it works. An IDE will do magic to make your life easier but will keep you ignorant.

You then take it a step further and learn to create your own make-file. This is a valuable skill. Your make-file makes the build cycle approach the convenience of "IDE magic" while still retaining full understanding and learning.

In addition your build process is easy to put in source control. And it's easy to port your build process to work with a variety of compilers. Sometimes it's just a matter of changing 1 line in the make-file for the compiler name.

You develop skills that allow you to work many platforms. Text editors and command line compilers are very similar from all vendors and on all platforms. These basic tools give you a pass to develop on any system, any time, any where 24/7. If you've been living in Visual Studio all your life, it's going to be a much harder transition to work outside of it.

If you go down this path you may want to bother to learn an advanced text editor like VIM. It complements the ability to work on any platform since it's supported almost everywhere. It has a huge learning curve but the pay off is the ability to edit text effortlessly at high speed without moving your hands to the mouse.

BTW, I am not against IDEs.

share|improve this answer
Thanks @LordTydus the make file recommendation is really helpful and getting right into how things work at low levels is how I like to learn – br3w5 Sep 30 '12 at 14:49
Another advantage of using the command line is it is much easier to specify multiple files using wildcards, such as *.c -- the only way to do this with GUI's is to provide a pseudo command line edit box. – tcrosley Sep 30 '12 at 16:37

GUIs have the advantage of being able to use advanced visualisations. This can be extremely useful to make complex data meaningful.

Command lines, on the other hand, are often more powerful (e.g. fully scriptable) and also usually faster. The other answers have expanded on that – here I’d just like to mention that GUIs don’t offer an advantage for some tasks:

In development, many tasks don’t actually need any visualisation that cannot be done using a command line / text interface. Take compiling: good text editors (Vim, Emacs) readily support error message parsing and will jump directly to the error in the code. Graphical IDEs don’t offer more. Simply put, for such tasks there is no need for a graphical interface, and you’d lose the flexibility and efficiency of a command line interface.

On the other hand, an interactive visualisation can be very useful if you’re dealing with a complex data interaction. Version control software which can display branch graphs often beat text interfaces here. For instance, this is a snapshot from one of my repositories:

branch graph

This is much more convenient than the text interface, even though this isn’t even a particularly powerful visualisation. But once again, note that actually manipulating the repository is faster using the command line (at least for me). I use the GUI just to display the branches.

Also note how Github has recently added a command line interface in recognition of the fact that many tasks can be accomplished faster by typing in a command than by clicking through a web page.

share|improve this answer

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