Overview

Teaching: 25 min
Exercises: 0 min
Questions
  • How can I perform the same actions on many different files?

Objectives
  • Write a loop that applies one or more commands separately to each file in a set of files.

  • Trace the values taken on by a loop variable during execution of the loop.

  • Explain the difference between a variable’s name and its value.

  • Explain why spaces and some punctuation characters shouldn’t be used in file names.

  • Demonstrate how to see what commands have recently been executed.

  • Re-run recently executed commands without retyping them.

Loops

are key to productivity improvements through automation; they allow us to execute commands repetitively. Similar to wildcards and tab completion, using loops also reduces the amount of typing (and typing mistakes). Suppose we have several hundred genome data files named basilisk.dat, unicorn.dat, and so on. In this example, we’ll use the creatures directory which only has two example files, but the principles can be applied to many many more files at once. We would like to modify these files, but also save a version of the original files, naming the copies original-basilisk.dat and original-unicorn.dat. We can’t use:

$ cp *.dat original-*.dat

because that would expand to:

$ cp basilisk.dat unicorn.dat original-*.dat

This wouldn’t back up our files, instead we get an error:

output

This problem arises when cp receives more than two inputs. When this happens, it expects the last input to be a directory where it can copy all the files it was passed. Since there is no directory named original-*.dat in the creatures directory we get an error.

Instead, we can use a loop to do some operation once for each thing in a list. Here’s a simple example that displays the first three lines of each file in turn:

$ for filename in basilisk.dat unicorn.dat
> do
>    head -n 3 $filename
> done

output

When the shell sees the keyword for, it knows to repeat a command (or group of commands) once for each thing in a list. For each iteration, the name of the each thing is sequentially assigned to the variable and the commands inside the loop are executed before moving on to the next thing in the list. Inside the loop, we call for the variable’s value by putting $ in front of it. The $ tells the shell interpreter to treat the variable as a variable name and substitute its value in its place, rather than treat it as text or an external command.

In this example, the list is two filenames: basilisk.dat and unicorn.dat, separated by a space. Each time the loop iterates, it will assign a file name to the variable filename and run the head command. The first time through the loop, $filename is basilisk.dat. The interpreter runs the command head on basilisk.dat, which prints the first three lines of basilisk.dat. For the second iteration, $filename becomes unicorn.dat. This time, the shell runs head on unicorn.dat and prints the first three lines of unicorn.dat. Since the list was only two items, the shell exits the for loop.

When using variables it is also possible to put the names into curly braces to clearly delimit the variable name: $filename is equivalent to ${filename}, but is different from ${file}name. The {} way is often a bit safer because it explicitly separates your variable name from the text around it.

Follow the Prompt

The shell prompt changes from $ to > and back again as we were typing in our loop. The second prompt, >, is different to remind us that we haven’t finished typing a complete command yet. A semicolon, ;, can be used to separate two commands written on a single line.

Same Symbols, Different Meanings

Here we see > being used a shell prompt, whereas > is also used to redirect output. Similarly, $ is used as a shell prompt, but, as we saw earler, it is also used to ask the shell to get the value of a variable.

If the shell prints > or $ then it expects you to type something, and the symbol is a prompt.

If you type > or $ yourself, it is an instruction from you that the shell to redirect output or get the value of a variable.

🤔 Maybe if there were more characters available back in the day, we wouldn’t have this problem?

We have called the variable in this loop filename in order to make its purpose clearer to human readers. The shell itself doesn’t care what the variable is called; if we wrote this loop as:

for x in basilisk.dat unicorn.dat
do
    head -n 3 $x
done

or:

for temperature in basilisk.dat unicorn.dat
do
    head -n 3 $temperature
done

it would work exactly the same way. Try to avoid this. Programs are only useful if people can understand them, so meaningless names (like x) or misleading names (like temperature) increase the odds that the program won’t do what its readers think it does.

Here’s a slightly more complicated loop:

for filename in *.dat
do
    echo $filename
    head -n 100 $filename | tail -n 2
done

output

The shell starts by expanding *.dat to create the list of files it will process. The loop body then executes two commands for each of those files. The first, echo, just prints its command-line parameters to standard output. In this case, since the shell expands $filename to be the name of a file, echo $filename just prints the name of the file. Note that we can’t write this as:

for filename in *.dat
do
    $filename
    head -n 100 $filename | tail -n 2
done

because then the first time through the loop, when $filename expanded to basilisk.dat, the shell would try to run basilisk.dat as a program.

Finally, the head and tail combination selects lines 98-100 from whatever file is being processed (assuming the file has at least 100 lines).

Spaces in Names, Just Say No!

Whitespace is used to separate the elements on the list that we are going to loop over. If on the list we have elements with whitespace we need to quote those elements and our variable when using it. Suppose our data files are named:

red dragon.dat
purple unicorn.dat

We need to use

for filename in "red dragon.dat" "purple unicorn.dat"
do
    head -n 100 "$filename" | tail -n 20
done

If we are getting our filenames more programmatically, we can run into real trouble.

It is simpler just to avoid using whitespaces (or other special characters) in filenames.

Going back to our original file copying problem, we can solve it using this loop:

for filename in *.dat
do
    cp $filename original-$filename
done

For Loop in Action

This loop runs the cp command once for each filename. The first time, when $filename expands to basilisk.dat, the shell executes:

cp basilisk.dat original-basilisk.dat

The second time, the command is:

cp unicorn.dat original-unicorn.dat

Nelle’s Pipeline: Processing Files

Nelle is now ready to process her data files. Since she’s still learning how to use the shell, she decides to build up the required commands in stages using just a subset of her files at first. Her first step is to make sure that she can select the right files — remember, these are ones whose names end in ‘A’ or ‘B’, rather than ‘Z’. Starting from her PIL-data directory, Nelle types:

$ cd north-pacific-gyre/2012-07-03
$ for datafile in *[AB].txt
> do
>     echo $datafile
> done

output

Her next step is to decide what to call the files that the goostats analysis program will create. Prefixing each input file’s name with “stats” seems simple, so she modifies her loop to do that:

$ for datafile in *[AB].txt
> do
>     echo $datafile stats-$datafile
> done

output

She hasn’t actually run goostats yet, but now she’s sure she can select the right files and generate the right output filenames.

Typing in commands over and over again is becoming tedious, though, and Nelle is worried about making mistakes, so instead of re-entering her loop, she presses the up arrow. In response, the shell redisplays the whole loop on one line (using semi-colons to separate the pieces):

$ for datafile in *[AB].txt; do echo $datafile stats-$datafile; done

Using the left arrow key, Nelle backs up and changes the command echo to bash goostats:

$ for datafile in *[AB].txt; do bash goostats $datafile stats-$datafile; done

output

When she presses Enter, the shell runs the modified command. However, nothing appears to happen — there is no output. After a moment, Nelle realizes that since her script doesn’t print anything to the screen any longer, she has no idea whether it is running, much less how quickly. She kills the running command by typing CTRL+C, uses up-arrow to repeat the command, and edits it to read:

$ for datafile in *[AB].txt; do echo $datafile; bash goostats $datafile stats-$datafile; done

Beginning and End

We can move to the beginning of a line in the shell by typing Ctrl-A and to the end using Ctrl-E.

When she runs her program now, it produces one line of output every five seconds or so:

output

… and oops! we left the beginnings of the aborted run, stats-stats-NENE01729A.txt which matched our wildcard expansion. We’ll just remove that one file with rm.

For Nelle’s fill data set, she has more than 1,500 files! 1518 times 5 seconds, divided by 60, tells her that her script will take about two hours to run. As a final check, she uses cat stats-NENE01729B.txt to examine one of the output files. It looks good, so she decides to run a loop on the full list of files, then goes to get some coffee and catch up on her reading.

Those Who Know History Can Choose to Repeat It

Another way to repeat previous work is to use the history command to get a list of the last few hundred commands that have been executed, and then to use !123 (where “123” is replaced by the command number) to repeat one of those commands. For example, if Nelle types this:

$ history | tail -n 5
  456  ls -l NENE0*.txt
  457  rm stats-NENE01729B.txt.txt
  458  bash goostats NENE01729B.txt stats-NENE01729B.txt
  459  ls -l NENE0*.txt
  460  history

then she can re-run goostats on NENE01729B.txt simply by typing !458.

Other History Commands

There are a number of other shortcut commands for getting at the history. Two of the more useful are !!, which retrieves the immediately preceding command (you may or may not find this more convenient than plain up-arrow), and !$, which retrieves the last word of the last command. That’s useful more often than you might expect: after bash goostats NENE01729B.txt stats-NENE01729B.txt, you can type less !$ to look at the file stats-NENE01729B.txt, which is quicker than doing up-arrow and editing the command-line.

Variables in Loops

Suppose that ls initially displays:

fructose.dat    glucose.dat   sucrose.dat

What is the output of:

for datafile in *.dat
do
    ls *.dat
done

Now, what is the output of:

for datafile in *.dat
do
	ls $datafile
done

Why do these two loops give different outputs?

Solution

Loop 1:

fructose.dat    glucose.dat   sucrose.dat
fructose.dat    glucose.dat   sucrose.dat
fructose.dat    glucose.dat   sucrose.dat

Loop 2:

fructose.dat
glucose.dat
sucrose.dat

This is because in the first case, ls is actually receiving an expanded list of all files in the directory for each time the loop runs. The second loop gives ls just a single file to list for each iteration: the current value of $datafile.

Saving to a File in a Loop - Part One

In the same directory, what is the effect of this loop?

for sugar in *.dat
do
    echo $sugar
    cat $sugar > xylose.dat
done
  1. Prints fructose.dat, glucose.dat, and sucrose.dat, and the text from sucrose.dat will be saved to a file called xylose.dat.
  2. Prints fructose.dat, glucose.dat, and sucrose.dat, and the text from all three files would be concatenated and saved to a file called xylose.dat.
  3. Prints fructose.dat, glucose.dat, sucrose.dat, and xylose.dat, and the text from sucrose.dat will be saved to a file called xylose.dat.
  4. None of the above.

Solution

1

Saving to a File in a Loop - Part Two

In another directory, where ls returns:

fructose.dat    glucose.dat   sucrose.dat   maltose.txt

What would be the output of the following loop?

for datafile in *.dat
do
    cat $datafile >> sugar.dat
done
  1. All of the text from fructose.dat, glucose.dat and sucrose.dat would be concatenated and saved to a file called sugar.dat.
  2. The text from sucrose.dat will be saved to a file called sugar.dat.
  3. All of the text from fructose.dat, glucose.dat, sucrose.dat and maltose.txt would be concatenated and saved to a file called sugar.dat.
  4. All of the text from fructose.dat, glucose.dat and sucrose.dat would be printed to the screen and saved to a file called sugar.dat

Solution

3

Limiting Sets of Files

In the same directory, where ls returns (without the sugar.dat file):

fructose.dat    glucose.dat   sucrose.dat   maltose.txt

What would be the output of the following loop?

for filename in s*
do
    ls $filename
done
  1. No files are listed.
  2. All files are listed.
  3. Only fructose.dat, glucose.dat and maltose.txt are listed.
  4. Only sucrose.dat is listed.

How would the output differ from using this command instead?

for filename in *s*
do
    ls $filename
done
  1. The same files would be listed.
  2. All the files are listed this time.
  3. No files are listed this time.
  4. The file sucrose.dat will be listed twice, with the other files listed once each.

Solution

4, 2

Nested Loops

Suppose we want to set up up a directory structure to organize some experiments measuring the growth rate under different sugar types and different temperatures. What would be the result of the following code:

for sugar in fructose glucose sucrose
do
    for temperature in 25 30 37 40
    do
        mkdir $sugar-$temperature
    done
done

Solution

you get the following directories:

fructose-25  fructose-37  glucose-25  glucose-37  sucrose-25  sucrose-37
fructose-30  fructose-40  glucose-30  glucose-40  sucrose-30  sucrose-40

Key Points