OK, you have quotes around your variable as the previous recipe recommended.
1 2 3 4 5 |
# for FN in $* do chmod 0750 "$FN" done |
It has to do with the $* in the script, used in the for loop.
For this case we need to use a different but related shell variable, $@.
When it is quoted, the resulting list has quotes around each argument separately.
The shell script should be written as follows:
1 2 3 4 5 6 7 8 9 10 |
#!/usr/bin/env bash # cookbook filename: chmod_all.2 # # change permissions on a bunch of files # with better quoting in case of filenames with blanks # for FN in "$@" do chmod 0750 "$FN" done |
The parameter $* expands to the list of arguments supplied to the shell script. If you invoke your script like this:
1 |
$ myscript these are args |
then $* refers to the three arguments these are args. And when used in a for loop, such as:
1 |
for FN in $* |
then the first time through the loop, $FN is assigned the first word (these) and the second time, the second word (are), etc.
If the arguments are filenames and they are put on the command line by pattern matching, as when you invoke the script this way:
1 |
$ myscript *.mp3 |
then the shell will match all the files in the current directory whose names end with the four characters .mp3, and they will be passed to the script.
So consider an example where there are three MP3 files whose names are:
1 2 3 |
vocals.mp3 cool music.mp3 tophit.mp3 |
The second song title has a blank in the filename between cool and music. When you invoke the script with:
1 |
$ myscript *.mp3 |
you’ll get, in effect:
1 |
$ myscript vocals.mp3 cool music.mp3 tophit.mp3 |
If your script contains the line:
1 |
for FN in $* |
that will expand to:
1 |
for FN in vocals.mp3 cool music.mp3 tophit.mp3 |
which has four words in its list, not three.
The second song title has a blank as the fifth character (cool music.mp3), and the blank causes the shell to see that as two separate words (cool and music.mp3), so $FN will be cool on the second iteration through the for loop.
On the third iteration, $FN will have the value music.mp3 but that, too, is not the name of your file.
You’ll get file-not-found error messages.
It might seem logical to try quoting the $* but
1 |
for FN in "$*" |
will expand to:
1 |
for FN in "vocals.mp3 cool music.mp3 tophit.mp3" |
and you will end up with a single value for $FN equal to the entire list. You’ll get an error message like this:
1 2 |
chmod: cannot access 'vocals.mp3 cool music.mp3 tophit.mp3': No such file or directory |
Instead you need to use the shell variable $@ and quote it. Unquoted, $* and $@ give you the same thing. But when quoted, bash treats them differently.
A reference to $* inside of quotes gives the entire list inside one set of quotes, as we just saw.
But a reference to $@ inside of quotes returns not one string but a list of quoted strings, one for each argument.
In our example using the MP3 filenames:
1 |
for FN in "$@" |
will expand to:
1 |
for FN in "vocals.mp3" "cool music.mp3" "tophit.mp3" |
and you can see that the second filename is now quoted so that its blank will be kept as part of its name and not considered a separator between two words.
The second time through this loop, $FN will be assigned the value cool music.mp3, which has an embedded blank.
So be careful how you refer to $FN—you’ll probably want to put it in quotes too, so that the space in the filename is kept as part of that string and not used as a separator.
That is, you’ll want to use “$FN” as in:
1 |
$ chmod 0750 "$FN" |
Shouldn’t you always use “$@” in your for loop?
Well, it’s a lot harder to type, so for quick-and-dirty scripts, when you know your filenames don’t have blanks, it’s probably OK to keep using the old-fashioned $* syntax.
For more robust scripting though, we recommend “$@” as the safer way to go.
We’ll probably use them interchangeably throughout this book, because even though we know better, old habits die
hard—and some of us never use blanks in our filenames! (Famous last words.)