WSU Tri-Cities CptS 360 (Spring, 2022)

Lab 11: Command Line Processing

This lab will introduce you to the facilties POSIX (and GNU) provide for command line processing and environment variable queries. These are the standard ways to pass parameters to a program.

The distinction between "parameter" and "datum" is a fine one. Technically, all parameters are (input) data, but one way to make a distinction might be to say that parameters are distinct, single data values (or a small list of them) that have a significant effect on how a program operates. They may be of any type, including (frequently) Booleans. Parameters can be specified as command line options. They may also be environment variables. Data, on the other hand, usually comes in large quantities and is often stored in files. The name of a file may be an option, but its contents are data.

The distinction between "option" and "argument" is also worth mentioning. Not surprisingly, options are (usually) optional: programs do something even if you don't provide any options. Arguments are lower-level: A command line option will require one or more arguments (the first one beginning with "-") to implement. Also, arguments may not be options:

In:

cc -g -o foo foo.c

"-g" is an option and "-o foo" is an option, but "foo.c" is an argument, not an option.

Many programs use options to give the user flexibility in just what the program does. Providing them on the command line rather than, say, prompting the user for them allows the programs to be incorporated into scripts. The result can be very powerful. Virtually all POSIX shell commands provide them.

This page will be available as

http://www.tricity.wsu.edu/~bobl/cpts360/lab11_getopt/writeup.html

Calling it up in a browser will allow you to cut-and-paste code in the following and save typing. You may also download whole files from the lab link on the course web page.

We'll start with a program that plays a simple but fun game and add command line options and environment variables to permit the user to change the length and/or difficulty of the game.

Every part after Part 1 depends on the part that went right before it, so be sure that part is working before you move on.

Part 1: The lander Program

A classic computer game called "lunar lander" simulates this:

You're at the controls of a probe landing on the surface of the Moon. The probe starts out at a given height above the surface travelling downward at a given velocity with a given amount of fuel. At (simulated) one second intervals, you determine how much fuel to burn (from 0 to a given maximum) to slow the probe's fall. If you land at less than 2 meters per second, you land safely. Otherwise, you crash. If you run out of fuel, the probe will free-fall and (probably) crash.

For this part, of the lab:

Part 2: Creating a parameters Structure and Using Environment Variables

In this part, we'll modify lander to use a struct to hold just one parameter (for now) and use environment variables to set it. Here are the steps:

Part 3: Calling getopt(3)

In this part, we'll use getopt(3) to process command line arguments in a convenient and flexible way.

Part 4: Adding More Options

Following the pattern set in Parts 2 & 3, we'll add a few more parameters to give the user more control and flexibility. We'll make use of this table:

environment variable #define default parameter member (short) option
INITIAL_FUEL INITIAL_FUEL_DEFAULT initialFuel -f
GRAVITY GRAVITY_DEFAULT gravity -g
INITIAL_HEIGHT INITIAL_HEIGHT_DEFAULT initialHeight -h
MAX_THRUST MAX_THRUST_DEFAULT maxThrust -t
INITIAL_VELOCITY INITIAL_VELOCITY_DEFAULT initialVelocity -v

Perform these steps:

Part 5: Calling getopt_long(3)

Long (or "keyword") options are especially useful in scripts, when you might not remember what the short option did when you look at the script six months later. In this part, we'll add long option versions to all the short options so that:

$ lander_pt5 -f200

means the same thing as:

$ lander_pt5 --initial-fuel=200

Here are the steps: