Very Computer

The backup command bru takes an optional Label argument like this:

bru -L "Useful label information" -cvf /dev/nst0 /dir1

In a sh script I'm writing I want to take /dir from the command line
(easy) and put it into the label field with the time. Something along the
lines of:

#!/bin/sh
DIR=$1
LABEL="$(date) $DIR"
BRUCMD="bru -L $LABEL -cvf /dev/nst0 $DIR"

echo $BRUCMD

$BRUCMD

the echo gives back exactly what I want to see:

bru -L "Fri Jun 12 20:59:42 EDT 1998 /dir1" -cvf /dev/nst0 /dir1

but when the command executes the quote marks have disappeared and bru
chokes on everything after Fri.

I'm sure this is something quite simple I'm missing, but I've already
wasted too much time on it.

Any suggestions?

thanks in advance,
Matt

Try combining single and double quotes, for example like this:
    ...
    BRUCMD='bru -L "$LABEL" -cvf /dev/nst0 $DIR'
    ...

Hope this helps

Quote:> The backup command bru takes an optional Label argument like this:

> bru -L "Useful label information" -cvf /dev/nst0 /dir1

> In a sh script I'm writing I want to take /dir from the command line
> (easy) and put it into the label field with the time. Something along the
> lines of:

> #!/bin/sh
> DIR=$1
> LABEL="$(date) $DIR"
> BRUCMD="bru -L $LABEL -cvf /dev/nst0 $DIR"

> echo $BRUCMD

> $BRUCMD

> the echo gives back exactly what I want to see:

> bru -L "Fri Jun 12 20:59:42 EDT 1998 /dir1" -cvf /dev/nst0 /dir1

Two notes:

$() only works if you /bin/sh is in fact ksh. Might as well admit it
in the first line.

To insert double quotes into your command string, protect them with
backslashes:
BRUCMD="bru -L \"$LABEL\" -cvf /dev/nst0 $DIR"

Look up the way ksh parses its command line and the effect of quotes,
either in the man page ot a good book, like "Learning the Korn Shell"
from O'Reilly.

That was three notes. Sorry.

Btw, you don't need eval, as somebody else suggested, in this case.
But to judge that you have to know when the shell expands variables.

Christian
--
Christian Bauernfeind
Not speaking for Siemens
Not even working for IBM

Quote:> > LABEL="$(date) $DIR"
> > BRUCMD="bru -L $LABEL -cvf /dev/nst0 $DIR"

Quote:> $() only works if you /bin/sh is in fact ksh. Might as well admit it
> in the first line.

So $() will work since /bin/sh in Linux is bash.  (I'm not even sure
a true Bourne shell is available in Linux, not counting ash from BSD.)
That doesn't mean you shouldn't start the script with #!/bin/bash,
however....

Quote:> Btw, you don't need eval, as somebody else suggested, in this case.
> But to judge that you have to know when the shell expands variables.

--
Peter Samuelson
<sampo.creighton.edu ! psamuels>

Quote:

>>Btw, you don't need eval, as somebody else suggested, in this case.

> I suggested that, and I did mention that it wasn't needed in this
> case, but that it's more general.

Christian

--
Christian Bauernfeind
Not speaking for Siemens
Not even working for IBM

Thanks everybody for your reponse & learned discussion.

I negelected to point out that the value of LABEL (see below) and the
refernce in BRUCMD (ibid.) had the quote escaped. I'd tried that along
with several other things before eval was suggested & wasn't sure if
escaping the quotes was part of the problem or part of the solution.

BTW: yes, this is bash under Redhat 5.

Here's where I ended up:

#!/bin/sh
DIR=$1
LABEL="$(date) $DIR"
BRUCMD="bru -L \"$LABEL\" -cvf /dev/nst0"

(eval $BRUCMD > $LOGFILE) 2>&1

...cut! print! on to the next mess ...

Thanks again,
Matt

Quote:

> The eval _is_ needed because without it, the quotes will not be
> stripped away. The processing of quotes takes place BEFORE the
> expansion of shell variables. Thus if you write

>    $BRUCMD

> it will expand into a bunch of tokens that will only be analyzed
> for whitespace separation only! The quotes will not be processed.
> So the resulting command line will be:

>    {BRU}{-L}{"Mon}{Jul}{15}{10:26:01}{GMT-8:00}{1998"}{-cvf}{/dev/nst0}

What I should've suggested is

LABEL="\"$(date) $DIR\""
BRUCMD="bru -L $LABEL -cvf /dev/nst0"
$BRUCMD

Christian
--
Christian Bauernfeind
Not speaking for Siemens
Not even working for IBM