This chapter discusses interaction with the user in shell scripts. Objectives important to this chapter are:
Concepts:Interacting with the user is at the heart of any programming assignment. If a programmer fails to communicate with the user, the program will fail to serve the user. The read command is used to take input on the user's command line and store it in script variables. Like most script commands, read can take multiple arguments. This means that it can be told to read several times with one call. In this example: echo "Please enter your name, separated by spaces (first middle last):" read fname mname lname we first ask the user for input, and give an example of the way we would like it done. This is an often overlooked step that can save you hours of trouble call time later. Show the user how to use the software. We then use the read command to look for input and give it three variables to hold the input. In this example, we asked for three words as a response, and set up three variables to receive it. If the user types more than three words as a response, the third and later words will all be stored in the third variable. Beginning on page 255, the author walks us through the creation of a more ambitious project. It would be best for the student to actually create this application to learn the details of it. The first interesting part is that it is menu driven. The basic design for the menu presentation is on pages 256 and 257. This menu in this script starts with a loop that contains the rest of the script. It is an infinite loop, in the sense that it begins with the statement while : Which means "while NULL", which will return the value 0. This means that this loop will always run and its test can never become false. Therefore the loop will run until something special happens to stop it. The author has designed a way out. Inside the loop, the menu is drawn on the screen for the user. The script then waits for input from the user which is compared to patterns in a case structure. One pattern is the letter X, which stands for the choice to exit the loop (and consequently, the script.) Before the loop itself, the author places an if structure to create his list of items to do (in case it does not exist). His test if [ ! -f $HOME/items ] looks for a file in the user's home directory called items. This test is passed it the file does not exist. As a consequence of the file not existing, the script creates the file with the touch command touch $HOME/items which creates an empty file. It would have merely updated the date associated with the file if it existed already. Within the case structure are the areas where we will place commands to take actions associated with the menu choices. A procedure to enter data into the file is illustrated on page 259. The new concept here has to do with default values. A user may be asked for a value for a given variable, but the user is not compelled to supply it. In cases in which the user may not know what to enter, it is good to have a default value to supply to the script. The third example on page 261:
${name:=default}
is the best choice for this exercise, as it will assign a value (default) to the variable (name) if that variable is NULL. A list of statements on page 262 shows various ways to approach this concept. When deciding on the action to take when a value is not available, consider this list. Four tasks that are menu options in the todo application are listed on page 263:
These tasks are discussed in detail in the pages following. Changing the value of the file to save to is quite simple, and could be done in a number of ways. Prompting the user for input is quite simple and might be followed by this test if [ $# -gt 1 ] then datafile=$1 else datafile=$HOME/items fi Of course, this is trusting the user to enter a proper filename in the proper spot. A second test is offered, based on the list of assignment types:
datafile=${1-$HOME/items}
This is functionally equivalent to the if structure above, and corrects the typo on page 264. It says, the variable datafile is equal to the first parameter from the command line, if there was one, and equal to $HOME/items if there was no first parameter. Code to invoke an editor is offered on page 264:
EDITOR=${EDITOR-vi}
$EDITOR $datafile
The first line sets the environment variable EDITOR equal to its current value if any, and equal to vi if no value is already stored there. Of course, a thoughtful script writer could substitute pico for the default value of the editor, saving the user from the ravages of vi. The second line calls the editor program and feeds it the value of the variable datafile. To shorten this discussion, it is most simple to list a file with more $datafile which passes the file through the more program. This is more flexible than using cat, which does not pause between screens. Sorting the data file is more flexible than you might imagine. Simply using the command sort -r $datafile will sort it on the first column, in descending order. To sort on another column, as you will wish to do, consider the number of fields on a line of the text file. In this example, there are four fields on each line. To sort on the third field, the date, we instruct the sort command to skip the first two fields (+2) and to stop considering material to sort on at the end of the third field (-3): sort +2 -3 $datafile Both parameters to the sort command are required: how many fields to skip and the last field to consider in the sort. A listing of the todo application is on pages 268-270. It is recommended that the student input it for practice and testing.
|