> Mike Gerdts wrote:
> > On 6/6/07, Michael Shapiro <[EMAIL PROTECTED]>
> wrote:
> [snip]
> > One nit.  In the Quoting section it says:
> > 
> >     Use whatever quotes are appropriate for your
> situation, but please
> >     do not unnecessarily quote everything (also see
> 7 above).
> > 
> > The numbers for the sections are missing but I
> think it refers to the
> > reference to ${bar} vs. ${bar}.  Rather
> unfortunately, in that section
> > there is gratuitous quoting.
> > 
> >     [ $install = yes ] && root="/a/" || root="/"
> > 
> > The stuff to the right of each root= doesn't need
> quotes.
> 
> If the variable "root" contains a filename as value
> then quotes should
> be used.
> IMHO _ALWAYS_ with _ZERO_ exceptions.
> Otherwise you'll run into "funny" problems with
> things like $ rm -rf
> $root/foo/bar/$snap # when either "snap" or "root"
> are not set. IMO the
> correct way would be $ rm -rf
> "${root}/foo/bar/${snap}" # (and scripts
> like "bfu" are full of this stuff which only waits to
> blow-up badly
> sooner or later... ;-( )

Right, but only when you have a $name reference do you need to
quote it; a constant being assigned, when it has no characters special
to the shell in it, doesn't really need quoting; thus in the cited line:
> >     [ $install = yes ] && root="/a/" || root="/"

The quotes on root="/a/" or root="/" don't matter, but $install ought to
be quoted.  On a test like that, it might also be safer if the constant
came first, as in

[ yes = "$install" ] ...
or else the old hack
[ x"$install" = x"yes" ] ...
(where I'd quote the constant just to make the parallel between the two
sides more clear; that leading x was to avoid the syntactical confusion
of "$install" having a value like "-f".

But in general, while I understand the advice not to quote unnecessarily,
nor to use curly braces unnecessarily, that seems a bit APLish to me
(i.e. back in the days where systems were so slow that in an interpreted
language, one wrote everything run together on one long line for speed); I'd
much rather massively overuse such syntactical elements insofar as
over-using them is far less likely to lead to undesirable behavior than
under-using them might.
 
 
This message posted from opensolaris.org
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to