Date: Thu, 2 Nov 2017 16:54:48 +0000
From: Michael F Gordon <michael.gor...@ee.ed.ac.uk>
Message-ID: <20171102165448.ga18...@ee.ed.ac.uk>
| Also, replacing := with :- gives "no" on both versions when unquoted
| or unquoted.
That's because they're doing different things, the := form assigns "" to
FOOFOOFOO, then expands ${FOOFOOFOO}. Expanding a var set to null produces
nothing, not a null string. In the :- case, if FOO is not set (or is null),
a null string results. [Incidentally, I believe that was the old bug
Chet referred to, the = operator in ${} expansions, used to return the word
assigned, similar to what the - operator does, rather than assigning the
value, and then expanding the variable, which is what it is supposed to do,
and now does - this example illustrates the difference.]
| I think I'll just rewrite this bit of the script to separate the
| assignment and test.
That would be a good idea, as the suggested workaround:
if [ -d "${FOOFOOFOO:=""}" ]; ...
is not really portable. In bash, and several other shells, it does what
it looks like it should do, but in posix (as it stands today) and in some
other shells, including the original Bourne shell, that is parsed as
if [ -d "${FOOFOOFOO:=""}" ]; ...
^=============v^=v
where the ^ indicates quoting starts, the v indicates quoting ends, and
the ='s are under quoted characters.
While this would work for this particular usage, as it is identical to
if [ -d "${FOOFOOFOO:=}" ]; ...
which assigns a null string to FOOFOOFOO and then expands "${FOOFOOFOO}"
which gives the expected null string (and would be entirely suitable as
an alternative formulation), but quoting in the word following the - + =
and ? operators in ${} expansions is a bad habit to get into as other similar
uses don't always work out so well.
For ref, this is being made unspecified in some later version of the
standard, which makes it even worse to use, as then shells will be able
to do almost anything they like when something like this is seen.
kre
ps: I'm not really sure what you're attempting to achieve here anyway,
if FOOFOOFOO is a null string already, assigning a different null string
to it doesn't really change anything. If the issue is just to make sure
it is set, then why? Unset vars produce the same null string value when
referenced as set ones do, just leave it unset...
