Console application design : Understanding command line arguments, options, switches

So there is a program. It's of a console application type. The way we execute it is we run at the command line/terminal.

Sometimes we can direct it to behave in a certain way by giving it parameters. These parameters follow the name of the program. These are also called options, switches.

For example, on windows command line, we can execute the command

C:\> dir /?

to get the help for the dir command.

Notice that we are using the "/?"

Traditional windows commands follow this syntax.

We can specify for example, use,

C:\> dir /q

to display the owners of the files..

Also sometimes we provide commands like

C:\> cd C:\Projects

to change the current directory to the one specified as an argument. In this case we are not asking the program to do something special. We are just asking to do something on something.

For example let's say we have a program that greets users beautifully named 'greet'. It might take command line arguments of many users and greet them

C:\> greet sameeri sasya madhu priya

Hello sameeri, sasya, madhu, priya! Welcome to the greet program.


These concepts are important to understand as most tools used in automation tend to be console applications.

For example. take a look at the C# compiler options.

Now this is the story for windows.

When you execute commands such as "dir" or "cd", they are run in the cmd.exe environment.

Windows also provides Powershell, a more powerful interface to the operating system.

Options are specified differently for commands in the powershell interface.

For example,

it uses the '-' instead of '/' to specify a switch.

For example on the powershell

C:\> dir -name

displays only names of the items in the current directory

Note:  

The 'dir' is an alias for a command called Get-ChildItem. Since most users tend to use dir or ls, there are aliases for the Get-ChildItem command.

You can also use *nix style commands such as ls in the powershell environment.

C:\> ls -name

has the same effect as the previous command.

But essentially when we are issuing either the "dir" or the "ls" commands, powershell executes the Get-ChildItem command internally!

So let's see options for this command.

Now, there is another style of specifying command line arguments. This originates from the Unix based environments.

Usually people use the "bash" shell to interact with the OS, although other shells do exist.

So for example.

the dir command in windows lists information about the items present in a directory.

In *nix, we have the ls command.

as we have seen earlier.

$ ls

To know more about ls, we can execute the command,

$ ls --help

We get something like this

Usage: ls [OPTION]... [FILE]...
List information about the FILEs (the current directory by default).
Sort entries alphabetically if none of -cftuSUX nor --sort.

  -a, --all                  do not hide entries starting with .
  -A, --almost-all           do not list implied . and ..
  -b, --escape               print octal escapes for nongraphic characters
      --block-size=SIZE      use SIZE-byte blocks
  -B, --ignore-backups       do not list implied entries ending with ~
  -c                         with -lt: sort by, and show, ctime (time of last
                               modification of file status information)
                               with -l: show ctime and sort by name
                               otherwise: sort by ctime

Notice that the help system displays a different style of options..
Each line specifies an option and there's a short version of the option in the first column and the long version of the command in the second column. The third column is a description as to how the command would behave.

For example,

we could specify

$ ls -a

or

$ ls --all

and both will have the same behavior.

On windows, the network commands such as ping, netstat, nslookup have a small version of the hyphen and the single character.

For ex: let's take a look at the ping command

Ping's using the hyphen single character option way.

So, there you go! That's three different styles of providing command line options, in three different environments.

Each environment has a consistent way of specifying options.

The one we have see about the *nix style, is based on an old specification called Getopt. It dates back to 1980 and is a standard as to how specify options.

You can read more about the Getopt to gain a better understanding.

Anyways, when we design our console application, we have to choose a style.

It might depend in which environment you run, but since we are going to study the Command Line Parser library, and using it in our C# projects, and it is based on Getopt, we shall see how we can make our console application parameters be awesomely based on the *nix style.

If you have used git, then you know that git has a verb style interface such as

$ git commit -m "Fixed broken code."

where 'commit' is the verb.

And the options that follow such as '-m' are called verb options or sub options.

This sort of a verb style approach is also supported in the library.

So yeah, command line options, arguments for you!

It's better to see some code in action, when we actually want to do something with the options provided in our application.