On 12/9/14, 9:47 AM, Stephane Chazelas wrote:
> 2014-12-09 07:14:16 -0700, Eric Blake:
> [...]
>> No, you get the correct behavior. Newer bash fixed the parser bug to
>> comply with POSIX.
>>
>> For comparison, try:
>>
>> $ echo . ${VAR:=""} .
>> . .
>> $ echo . "${VAR:=""}" .
>> . .
> [...]
>
>
On Dec 9, 2014, at 9:47 AM, Stephane Chazelas
wrote:
> It's a bit confusing that ${VAR:-""} should be treated
> differently from ${VAR:=""}. Was there a rationale for changing
> the behaviour other than strict POSIX conformance? AFAICT, ksh
> and mksh behave differently (from bash and from each
2014-12-09 07:14:16 -0700, Eric Blake:
[...]
> No, you get the correct behavior. Newer bash fixed the parser bug to
> comply with POSIX.
>
> For comparison, try:
>
> $ echo . ${VAR:=""} .
> . .
> $ echo . "${VAR:=""}" .
> . .
[...]
It's a bit confusing that ${VAR:-""} should be treated
differe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/9/14, 9:14 AM, Eric Blake wrote:
> No, with bash 3.2, you are tripping up on a parser bug. Bash 3.2
> incorrectly handled double quotes inside unquoted parameter
> expansion.
This is mostly true, but it has nothing to do with the parser. This
On 12/9/14, 8:24 AM, Olivier TROCHERIE wrote:
> I would like to report to you a problem I encounter with bash 4.3.30.
>
> In the following example, VAR is undefined.
>
>
>
> With bash 3.2, when I run the following commands:
>
>
>
> if [ -d ${VAR:=""} ]
>
> then
>
> echo yes
>
> else
On 12/09/2014 06:24 AM, Olivier TROCHERIE wrote:
> With bash 3.2, when I run the following commands:
>
> if [ -d ${VAR:=""} ]
Insufficient quoting. You are executing:
[ -d ]
which is a test whether the single argument "-d" is not empty (which is
true), ergo the exit 0 status.
You MEANT to use
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown'
-DLOCALEDIR='/homedir/otroch