Most people who are using Windows are probably shaking every time they hear the term "command line". Others, who have been around long enough to witness the birth and fall of such operating systems as Windows 3.1 might remember it as a remnant of the past. Programmers, on the other hand, know it rather well. Same thing goes for Linux users. In fact, one of the things that Windows users fear the most about switching to Linux is the command line. However, the command line is not at all scary when you learn to use it, and in fact is a very handy tool.

I'll start this article by outlining some of the positive aspects of Graphical User Interfaces (GUI). When it was first introduced, it marked a new era of computer use, because with GUIs you can perform some actions a lot quicker. For instance, if you use a program with a Command Line Interface (CLI) and there is a parameter with multiple choices, you need to go into the manual pages, find the parameter, see the available options, then go back to the command line and make sure you spell both the parameter and the value correctly. With GUIs, it's a lot easier - you either have a drop-down box or a set of radio buttons, with text that indicates what those options do. All you need to do is to select one with your mouse. That shortens the time you spend dramatically. Since that is true for a lot more things, like menus, overall GUIs are a lot faster to use than CLIs. Not to mention that they look a lot more aesthetically, especially given modern compositing window managers like DWM, Compiz and KWin.

However, they are not always the best. Consider this simple every-day problem: you have a directory full of files. You made sure to back some of those up by renaming them from "Filename.ext" to "Filename-Backup.ext". But now you are low on space or want the folder to look clean, and you don't need the backups any more. What do you do? If you were using a GUI, like Windows Explorer, Konqueror or Dolphin, you would have to spend ages selecting each of the little icons that are scattered all across the window, also making sure that you don't miss anything. Even worse if you were trying to delete it one by one, always getting the annoying "Do you really wish to move this into the recycle bin?" prompt. However, if you were using a CLI, this task would be extremely simple. You would be able to complete it with a single command: rm *-Backup*.

Here's another example, similar to one you probably face every day. You want to start a program. You haven't used this program for a while, so you don't remember where exactly it is. You look over your cluttered desktop, but it's just not there. You then go to the Start menu and start going through each of the program groups in order to find the program. But you forgot who developed that program, so you can't find it in the Start Menu either! So now you can either go through every folder in the menu, hoping to find the program you're looking for, or go through every folder in your Program Files folder, or use the Search function that will take forever to complete and yield a lot of unnecessary results. However, if you were using a CLI, you would be able to launch the program by simply entering its name. Thankfully, GUI users don't have to face this problem any more since KDE 3.5 and Windows Vista, because you can now enter the name in the Start/K menu itself and you will see the program listed there. Unless, of course, that program did not install itself into the menu, in which case you're back to the original problem.

Now let's see a few less common examples. Imagine that you're a developer. You spend a lot of time creating this powerful program that is very rich in features. And now you have finished the program, but it is using a CLI, because it's universal, easy to do and available for every programming language without the need of any external libraries. So you are faced with a dilemma - should you release the program as-is, or spend a whole lot of time integrating a new, unfamiliar library, setting up your graphical interface, debugging it, making sure it looks good and still risk losing cross-platform compatibility or spend even more time and effort trying out your program in other OSs. Either way you would spend about as much time making a working GUI for your program as making the program itself! If the program was free and open source, then you would have a third option on Linux - you could release your program as a library or a back-end. Then you could take your time to release the GUI, or front-end, separately from the back-end. That would allow people to use the program before it gets a front-end or even start making a front-end themselves, so your program would have several of them to choose from. Windows has no package model, so that would be more complicated there, since custom GUIs and your own GUI could create a conflict.

There is one more awesome thing that can be used in command line that is almost never used in GUIs. That is the pipe, short for 'pipeline'. Pipes are unbelievably useful, because they join two programs together. The output of one program becomes the input of another. A very simple example (that even works on Windows!) is the program more. more is responsible for reading a file and displaying it on the terminal screen with an option to scroll it. For instance, if you have a large directory full of files (think C:\WINDOWS for Windows users, /usr/lib for Linux users) and you want to read through it. If you would simply list them, all you see would be the last few lines. So in order to read it all, you would have to tell the system to list it, then output it to more, which reads the input and presents it to you with the ability to scroll through it. To do that, on Windows you would do dir C:\WINDOWS | more and on Linux you would do ls -l /usr/lib | less (Because on Linux, less is more than more! Actually, less allows you to scroll back up, something more doesn't.) But that's a very simple use of it. You realise the power of it when you actually get to pipe together two entirely different programs, like SoX and FFmpeg. I use SoX, a sound recording and editing utility, to record audio, and FFmpeg, a video recording and editing utility, to record video. FFmpeg can also record sound, but it is limited, because it was designed with video in mind, while SoX was designed with audio in mind. Pair them together and you have yourself two expert tools working together in unison. And since pipes can be used for more than just two programs, you could for example take the output of FFmpeg and write it directly into an archiving application like gzip to have it compress the file on the fly.

Speaking of FFmpeg, that's one more place where CLIs shine. Remember how I said that CLIs were rather inconvenient because you have to go through manual pages to find out what argument to use? Well, with programs like FFmpeg that's actually a good thing. If you used an FFmpeg front-end, you would be overwhelmed by all the options presented by it and end up having a very low quality video file. However, since in this case you have to read through the manual, you learn about what each setting really does in detail, and that allows you to understand how it works and thus produce the optimal quality video.

Another place where CLIs take the cake are shell scripts. They are extremely helpful with executing a certain sequence of commands. I often create those to launch several programs together for convenience (like all my recording tools) or to start recording with optimal parameters. One of the annoying thing about GUIs is that you have to keep doing the same thing over and over again, like choosing rendering options each time you want to produce a video. Shell scripts allow you to circumvent just that - you can simply enter a word and it will repeat your steps immediately and automatically.

And finally, my thoughts on how GUIs could benefit from this. The thing is, GUIs, when created well enough, are always as good as CLIs, because after all, a CLI is the same as a GUI dialog with a textbox. First off, like I've said, barely any GUIs use pipes, but they do exist. One of the best examples is Kdenlive, a video editing software. It uses recordMyDesktop, an independent program, to capture videos. This could be expanded further, for example, instead of the "save" button have a "pipe" button, which would allow you to select a program, script or process to pipe the output to. This would allow you to use quality tools, created by people who know their field very well, and combine them into one.

In order to make sure shell scripts are not needed, they should use setting saving. Something along the lines of nLite. You can save your settings into various slots and load them. One should always be set to default and it should require you to do the least amount of repetitive things - for instance, have an option to save all the video project size options and rendering parameters and then do not prompt the user about it. Simply go straight for the editing part. Or skip that altogether, going straight into rendering.

What to do if you're making a front-end for a command line program which has tons of switches that all need to be explained? You can make a wizard/assistant, like nLite, that walks you through the process. It gives you plenty of space to work with, so you can explain things in quite some detail.

Lastly, they should have a manual CLI field. Much like Dolphin has, an integrated shell. That would allow you to launch things by using text input and would be easy to switch between CLIs and GUIs, using whichever is better suited for one task or another.

In conclusion, I have to say that CLIs, while may look frightening, are actually easy to use and are very rewarding. Learning to use them is definitely a good thing to do. And if you are a developer, you should make your program with a CLI first, and worry about the GUI later - that works a lot better than trying to use a GUI from the get-go. Unless, of course, you're creating a game... In which case a CLI could actually be a front-end. Arcomage with a CLI, that would actually be pretty awesome.