Friday, April 4, 2008

The Anatomy of a Command Line

Command Line

Command line needs no introduction among the computer folks. We all know what it is. Yet, many of the developers are really scared to work on the terminal; they rather prefer GUIs. Command line somehow makes them uncomfortable. They think it is tough. In fact, when they design their own application's command line interface, they forget some of the simple and basic things they should have taken care. It will be one of my agendas in this post.

You may read this post even if you are not a developer, this isn't a developer specific post.

Misconceptions/Preconceptions

There are two kinds of people who don't prefer command line:
  1. The ones who've used and quit because it looked tough at the beginning
  2. The ones who've never tried (I call it the startup-syndrome)
I went through both the phases until the bulb glowed over my head. It shouldn't be tough, computers are easy to use. After all, command line is not programming. It is aimed at the end user. The Operating System designers must have came up with some pattern before implementing these commands. Yes, the keyword is pattern.

The Basic Syntax

A command consists of three main parts:
  1. What to do?
  2. How to do?
  3. Other Inputs
Can You Show Me an Example?

Yes My Lord! Sure. Let's take an example. We will see the command line interface of the tail Unix utility. Here are the first few lines from the man page and I quote (please read it thoroughly once):
NAME
tail -- display the last part of a file

SYNOPSIS
tail [-F | -f | -r] [-q] [-b number | -c number | -n number] [file ...]

DESCRIPTION
The tail utility displays the contents of file or, by default, its stan-
dard input, to the standard output.
The part that is found difficult and that I would like to explain here is the SYNOPSIS. Remember the three main parts? The what? The how? And the other inputs? Let us see these three parts for this tail command.

The How part can be a little tricky for the newbies. You may even wander what is -f? -n? number? the "|" sign? Actually, that is what makes the command line interface friendly. This little table should help you understand about the syntax.
Anything inside []          = Optional
... = Can occur more than once
-something (or --something) = The How
option1 | option2 = Either option1 or option2 can appear

The "how" part can consist of two kinds of options. 1) Self descriptive options 2) Options that need more input.
tail -v -n 25 logs.txt
The "How" in the above command tells the tail command to print the last 25 lines of the file logs.txt and print the output in verbose mode. The below figure explains better.

The Design Difference

In a well designed graphical user interface, everything is presented to you. You need not remember or search for anything (like the -n option). GUIs follow the "push" model. Everything is pushed to you and you get to choose. You learn and discover things quickly. Whereas, in a command line interface, you need to tell what you want to do. You need to search and "pull" the options from the manual and tell the command "how" you want to execute it.

How *NOT* to Design a Command Line Interface

Have you ever used a command line that was like:
doSomething 49595 39504 "/usr/local/file" "/home/srikanths/dir/file"
You got the point. The "how" and the "other inputs" parts are totally messed up. You don't know the meaning of the numbers you are passing and even if you have a manual about this command, you need to refer it every time you use and you have to double check to make sure you pass the arguments correctly. A command line nightmare! Now, see the same command's better version:
doSomething\
-port 49595\
-fallbackPort 39504\
-configFile "/usr/local/file"\
-fallbackConfigFile "/home/srikanths/dir/file"
So, when you design a command line interface, make it more user friendly and follow the common pattern that is already there for decades now. There are many modules available either out of the box or as frameworks that can parse the command line arguments for you. Just search which ones are the most popular CLI frameworks for your language and choose one from that. Hope this post helped you!

Bottom Line

"The next time you tell someone RTFM, tell them how to RTFM."

References
Other posts

4 comments:

Manu said...

Nice post dude! Good analysis :)

Srikanth said...

Thanks Manu :)

Unknown said...

what makes a man a man- the way he uses his 'command line' :-)

Srikanth said...

@cipherskull: Although not rhyming, it's really cool to work on command line. On Windows, I prefer Launchy (http://launchy.net) to fire up programs without using mouse. I'm sure you know about this, but just in case.

Post a Comment