bash script command substitution and quoting

brian4xp · 02-04-2008, 06:39 PM

If I have a directory named tmp and I enter the following:

ls -l "tmp"

I will get a listing of the file(s) in the tmp directory.

total 4
-rw-rw-rw- 1 brian brian 15 Feb 4 19:34 file1.txt

(I can also use ls -l tmp of course, but my question involves the quoting)

Can anyone here explain the behavior of the following script:

Code:

#!/bin/bash
test1=" ls -l tmp"
echo "1st try" $test1
$test1

test2=" ls -l \"tmp\""
echo "2nd try" $test2
$test2

If I execute this script (which I have named test.sh) via ./test.sh I get the following:

1st try ls -l tmp
total 4
-rw-rw-rw- 1 brian brian 15 Feb 4 19:34 file1.txt
2nd try ls -l "tmp"
ls: "tmp": No such file or directory

So if I TYPE the ls -l "tmp" the command works correctly
And the script echoes the $test1 and $test2 correctly BUT when executing them the quotes are not interpreted correctly.

What is going on here?

colucix · 02-04-2008, 06:55 PM

If you escape double quotes, they lose their meaning and are interpreted literally. This means you are trying to list a file or directory called "tmp" (in the sense of quotes-ti-em-pi-quotes, a file name made of 5 characters).

gilead · 02-04-2008, 06:56 PM

It's not that the quotes are interpreted incorrectly, it's that different things are interpreting them. When you use the quotes on the command line (without escaping them), your shell interprets them and ls does not. When you escape them in your script, the shell does not interpret them and passes them to ls - ls looks for a directory with " characters in its name and there isn't one.

brian4xp · 02-04-2008, 09:21 PM

Ah, I see. So is there a way to make it work?

How can I build a command that requires the quotes into a variable and then execute it?

gilead · 02-04-2008, 09:39 PM

Do you mean like this?

Code:

$ test2='ls -l "tmp"'
$ echo $test2
ls -l "tmp"
$ eval $test2
total 0

pixellany · 02-05-2008, 04:12 AM

ABS (The Advanced Bash Scripting Guide---tldp.org) has a discussion on quoting which is quite good. The various combinations of single or double quotes inside of other single or double quotes will give you a headache quite quickly.

One way to think of it: As you pass a line of code through one program to another, each one wants to process it by its own rules (syntax). Quoting "protects" your code from that behavior. Start from the inside out---first look at the final command to be called and make the code correct for that. Then look at how that code will be seen by the next command up the chain. If that will not give the right answer, then you need quoting.

jschiwal · 02-05-2008, 04:35 AM

If you are interested in investigating different quotes, I would recommend using the "set" command.

Code:

set a "b c d"
jschiwal@lmax:~> echo $@
a b c d
jschiwal@lmax:~> echo $0
/bin/bash
jschiwal@lmax:~> echo $1
a
jschiwal@lmax:~> echo $2
b c d

jschiwal@lmax:~> test='test'
jschiwal@lmax:~> echo $1 : $2
a : b $test c
jschiwal@lmax:~> set a \"b $test c\"
jschiwal@lmax:~> echo $1 : $2 : $3 : $4
a : "b : test : c"

brian4xp · 02-05-2008, 11:32 AM

Thanks for the info.

Adding eval to the script worked.

My supervisor in the meantime came up with another solution that fit our needs better. We were updating our incremental backup script using the --newer-mtime option and our original command needed the quotes around the argument for that option. Our current solution though, is that our full backup script will create a timestamp file when it finishes. In our incremental backup we set a variable tsfile to this file and use --newer-mtime=$tsfile

This is better since it gives us an exact cutoff time from our full backup for our incremental backup to use.

jschiwal · 02-05-2008, 11:43 AM

If you use tar, there is an option to create & use a timestamp file. See section 5.2 in the tar info manual.