[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fix testsuite errors due to shell quoted parameter expansion issue.
From: |
Eric Blake |
Subject: |
Re: Fix testsuite errors due to shell quoted parameter expansion issue. |
Date: |
Wed, 04 Aug 2010 09:27:24 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Mnenhy/0.8.3 Thunderbird/3.1.1 |
[please don't top-post on technical lists]
On 08/04/2010 09:18 AM, John Lumby wrote:
>
> Re the statement
>
> since "$e" is quoted, it must not be elided
>
> I don't think that is correct. In fact "$e" *must* be elided - because
> you juxtaposed it with the next token. eliding and quoting are orthogonal.
Your statement is confusing to me. Here, in more detail, is exactly
what I meant (and what I though I implied in the first case):
The word in question is '"$e"$f' before either parameter substitution,
or word splitting, or quote elision.
After parameter substitution, you are left with '"" val', where a
portion of the string was originally quoted, but you also had a portion
of the string that was unquoted. Only the ' val' portion of the result
is subject to word splitting.
Because "$e" is quoted, the resulting empty string must not be elided
during word splitting.
Therefore, the result after word splitting MUST be the two words '""'
and 'val'; then you apply quote elision and are left with two words: ''
and 'val'.
>
> What you appear to be be expecting is that the effect of quoting one token
> should somehow have some effect on interpretation of a special character
> (blank) in a subsequent unquoted token. I don't think that is expected
> behaviour. The quoting of $e has the effect of quoting any special
> characters inside *it*, of which there are none. your blank is unquoted.
> Then word-spilling proceeds.
No, what I expect is that within a single word, the quoted portion of
the word must not be elided during word splitting, except in the special
case of "$@".
>
> What I find interesting is this
>
> bash -c 'declare -i length; f=" val" e=;concat="$e"$f; length=${#concat};
> echo "length= $length"'
> 4
Why do you find that interesting? There is NO word splitting in
assignment contexts, so the effect of
concat="$e"$f
is the same as if you had done
concat=$e$f
or
concat="$e$f"
in all three cases, concat is assigned the value ' val', which is indeed
length 4.
But it is unrelated to the bash bug at hand, which is that when "$e"$f
is in a context subject to word splitting, then it must result in the
two words '' and 'val', not the single word 'val'.
--
Eric Blake address@hidden +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Fix testsuite errors due to shell quoted parameter expansion issue., Mikael Magnusson, 2010/08/04
Re: Fix testsuite errors due to shell quoted parameter expansion issue., Chet Ramey, 2010/08/08