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/PreconceptionsThere are two kinds of people who don't prefer command line:
- The ones who've used and quit because it looked tough at the beginning
- 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 SyntaxA command consists of three main parts:
- What to do?
- How to do?
- 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 DifferenceIn 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 InterfaceHave 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."
ReferencesOther posts