Hari's Corner

As a fairly experienced Linux user, I keep discovering from time to time that the command line is a real boon at times when the GUI lets me down.

An example from my own recent experience to illustrate the point:

I wanted to rip and convert one of my new DVDs for the iPod Video. I always use acidrip, which is a Perl/GTK front end to mencoder. It hides a very complex command line in a fairly usable GUI. However, acidrip has its limitations. Why? It uses another command-line program called lsdvd which tries to read all the track information on the DVD to allow the user to choose which track/chapter to rip. This works nearly all the time, but the odd DVD does not have menu entries. In fact, the DVD I purchased recently didn't have any readable menus. As a result, acidrip aborted with an error message even at the DVD scanning stage and I couldn't continue. Other ripping GUI tools also use the same command line program to read the menus. I thought I was at an end and that the DVD was corrupt, but I found that I could play the individual .vob files using mplayer. I came to the realization that the only way I could rip was by directly using mencoder. And since I have to manually enter the chapter number in the mencoder command line, there is no necessity to scan the DVD entries. Needless to say, the process was successful. I managed to rip the movie although I was unable to do so with the usual GUI tool for the purpose. I can quote a dozen similar examples where GUI apps have let me down, but I think the point is quite clear.

I have to admit that having to mess with the command line isn't a walk in the park, particularly with complex applications like mencoder. Here is the kind of command I issued to rip a DVD chapter to my hard-drive.

mencoder dvd://5 -dvd-device /dev/hdc -vf scale=320:240 -oac mp3lame -lameopts br=64 -ovc lavc -lavcopts vcodec=mpeg1video:vbitrate=300 -o rip-file.mpg

If you read the mencoder man page, you would realize how long it took me to figure out each of these command line parameters simply because it is huge and required a lot of scrolling up and down. I didn't relish the prospect initially. It was a long, tedious process to get the options right but I had to do it this way or not at all and I didnt want to admit defeat knowing fully well that it was not an insurmountable problem. In fact, once I figured out enough to execute the command successfully, I felt that it was actually a better way to rip and encode because I had greater control over the individual codec features. I'm convinced that the power and flexibility of mencoder can never be experienced in a mere GUI. Any GUI that attempts to incorporate every single feature of mencoder will be 100 times more complex than mencoder itself.

The command line is a necessary part of the Linux experience. To be sure, beyond the initial system configuration, you can manage 90% of your tasks within a GUI and not all command line tools are as insanely complex as mencoder. But there will be situations where the GUI is insufficient, inadequate or just plain useless. At such times it will be not only be necessary, but actually desirable to fall back on the command line. If I could figure out the basics of mencoder in less than an hour, surely it would take a fraction of that time to learn other more basic, but essential tools. One common situation is when X refuses to start up after an upgrade and you need to tweak/configure its settings. Most new Linux users unfamiliar with the command line will end up wasting a lot of time reinstalling Linux to fix what is probably a trivial issue. On the other hand, experienced Linux users will know that editing one or two lines in xorg.conf can fix the issue. I still remember the days when I used to soft-reboot the computer to quit vim (in pure text mode). Thankfully I quickly realized that to survive in a Unix environment a basic working knowledge of command-line text editors will go a long way.

The other big advantage of familiarity with the command line is that it is also the most common aspect of all Unix-like operating systems. If you learn the basics of bash or sh, you can work with most Linux and *BSD systems. And this will definitely add to your knowledge and skill-set. Familiarity a variety of *nix Operating Systems can be extremely beneficial to your curriculum-vitae, particularly if you're in the IT/CS field.

Here is my personal list of essential command line skills:

1. All the base POSIX commands.
2. Knowledge of any command line text editor. nano/pico are very simple, easy to use editors while vim is a more powerful programmers' editor.
3. Knowledge of virtual terminals. Easy to use, yet extremely handy and convenient.
4. Knowledge of a text-based web browser like links or lynx (useful for browsing online documentation in the absence of an X server).
5. A little bit of scripting knowledge. Shell-scripting or basic Perl/Python scripting will do.

My advice to all new Linux users is to occasionally explore the command line and learn a little bit from time to time. It is a tiresome chore and it requires a degree of tedious memorization, but there are always man pages to help out which eases the learning curve somewhat and not everybody needs to become an expert. But when something in the GUI lets you down, you will always have a fail-safe option to fall back upon.