Unix Shell - Question re: braces and quotes

Author

Question re: braces and quotes

Peter

2006-10-30, 7:22 am

I was reviewing the Suse/Gentoo run-crons script, and comparing it with
some elementary scripts I had written. All of a sudden, I realized that
despite reading the docs and advanced scripting manual, I really did not
have a good grasp on the concept of when to quote, enclose in a brace, etc.

This snippet crystallizes my confusion. As written, the variable
definition for LOCKFILE uses braces, but I found that it made no
difference whether or not I used braces, quotes, or any combination. I
understand that certain test contructs, such as [ -n... ] require quotes,
and if I want to manipulate a variable, braces are useful for
substitution, but could someone please explain if the first assignment of
LOCKFILE is proper, and why? For that matter, when would the assignment to
LOCKDIR have to be quoted? If there is a whitespace?

Thanks a lot!

#!/bin/sh

LOCKDIR=/var/spool/cron/lastrun
LOCKFILE=${LOCKDIR}/lock

echo "braces no quotes $LOCKFILE"

LOCKFILE="${LOCKDIR}"/lock
echo "braces quote $LOCKFILE"

LOCKFILE=$LOCKDIR/lock
echo "no braces no quote $LOCKFILE"

LOCKFILE="$LOCKDIR"/lock
echo "no braces quote $LOCKFILE"

--
Peter

Barry Margolin

2006-10-30, 7:22 am

In article <Z6m1h.6506$Wy6.4104@trnddc01>,
"Peter" <peter@localhost.com> wrote:

> I was reviewing the Suse/Gentoo run-crons script, and comparing it with
> some elementary scripts I had written. All of a sudden, I realized that
> despite reading the docs and advanced scripting manual, I really did not
> have a good grasp on the concept of when to quote, enclose in a brace, etc.
>
> This snippet crystallizes my confusion. As written, the variable
> definition for LOCKFILE uses braces, but I found that it made no
> difference whether or not I used braces, quotes, or any combination. I
> understand that certain test contructs, such as [ -n... ] require quotes,
> and if I want to manipulate a variable, braces are useful for
> substitution, but could someone please explain if the first assignment of
> LOCKFILE is proper, and why? For that matter, when would the assignment to
> LOCKDIR have to be quoted? If there is a whitespace?
>
> Thanks a lot!
>
> #!/bin/sh
>
> LOCKDIR=/var/spool/cron/lastrun
> LOCKFILE=${LOCKDIR}/lock
>
> echo "braces no quotes $LOCKFILE"
>
> LOCKFILE="${LOCKDIR}"/lock
> echo "braces quote $LOCKFILE"
>
> LOCKFILE=$LOCKDIR/lock
> echo "no braces no quote $LOCKFILE"
>
> LOCKFILE="$LOCKDIR"/lock
> echo "no braces quote $LOCKFILE"

None of the above examples need the braces or quotes. But here are some
examples where they're necessary:

LOCKFILE=${LOCKDIR}1/lock

Without the braces, it would look for a variable named LOCKDIR1.

LOCKFILE="$LOCKDIR/lock file with spaces"

Without the quotes, it would set the environment variable to
$LOCKDIR/lock while trying to execute the command line "file with
spaces".

STRINGWITHSPACES="foo bar"
echo $STRINGWITHSPACES
echo "$STRINGWITHSPACES"

The first one loses the multiple spaces between the words.

However, you don't need it here:

OTHERSTRING=$STRINGWITHSPACES

because word splitting of the assignment portion of a command is done
before variable expansion.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Peter

2006-10-30, 7:22 am

On Mon, 30 Oct 2006 07:47:22 -0500, Barry Margolin wrote:

snip...
>
> None of the above examples need the braces or quotes.

Don't I feel like the dunce! Why do you think it WAS coded that way? Are
braces always "safe" to use -- that is, will bash always properly handle
it as a variable and expand it properly? What about quoted braces and
variables? When would they be required?

> But here are some examples where they're necessary:
>
> LOCKFILE=${LOCKDIR}1/lock
>
> Without the braces, it would look for a variable named LOCKDIR1.
>

Yes, I experienced that! Took a while to figure it out! So, the braces
encapsulate the variable.

> LOCKFILE="$LOCKDIR/lock file with spaces"
>
> Without the quotes, it would set the environment variable to
> $LOCKDIR/lock while trying to execute the command line "file with
> spaces".
>
Again, would braces be superfluous here?

> STRINGWITHSPACES="foo bar"
> echo $STRINGWITHSPACES
> echo "$STRINGWITHSPACES"
>
> The first one loses the multiple spaces between the words.
>

Tricky. Must be hell to debug something like that!

> However, you don't need it here:
>
> OTHERSTRING=$STRINGWITHSPACES
>

I love consistency! What if you DID use quotes? Same result?

> because word splitting of the assignment portion of a command is done
> before variable expansion.
>

thanks for the explanation!

Is there an easy way to generalize when braces are used? I have seen
assignments in the same script that inconsistently use it. Very hard for
an end user to understand!

For example, look at this line from run-crons:

# base is one of hourly, daily, etc. single word, no spaces
# lockdir has slashes but no spaces

if [ -e ${LOCKDIR}/cron.$BASE ]

Is BASE not quoted or braced because it is a single word with no escape
type chars? Why is LOCKDIR in braces? Why are quoted UNnecessary?

--
Peter

Bill Marcum

2006-10-30, 1:19 pm

On Mon, 30 Oct 2006 13:18:15 GMT, Peter
<peter@localhost.com> wrote:
> # base is one of hourly, daily, etc. single word, no spaces
> # lockdir has slashes but no spaces
>
> if [ -e ${LOCKDIR}/cron.$BASE ]
>
> Is BASE not quoted or braced because it is a single word with no escape
> type chars? Why is LOCKDIR in braces? Why are quoted UNnecessary?
>
As far as I know, it is always safe to use braces. Possibly the script
was written by two or more people, or the author had previously written
something that required braces, such as ${LOCKDIR:-default}

--
If your hands are clean and your cause is just and your demands are
reasonable, at least it's a start.