bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: read with parameter expansion in here string


From: Clint Hepner
Subject: Re: read with parameter expansion in here string
Date: Fri, 22 Nov 2013 17:38:53 -0500

On Nov 22, 2013, at 10:04 AM, Pierre Gaston <address@hidden> wrote:

> 
> 
> 
> On Fri, Nov 22, 2013 at 4:22 PM, Clint Hepner <address@hidden> wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i386
> OS: darwin13.0.0
> Compiler: clang
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' 
> -DCONF_OSTYPE='darwin13.0.0' -DCONF_MACHTYPE='i386-apple-darwin13.0\
> .0' -DCONF_VENDOR='apple' 
> -DLOCALEDIR='/usr/local/Cellar/bash/4.2.45/share/locale' -DPACKAGE='bash' 
> -DSHELL -DHAVE_CONFIG_H -DMA\
> COSX   -I.  -I. -I./include -I./lib -I./lib/intl 
> -I/private/tmp/bash-4vKN/bash-4.2/lib/intl  -DSSH_SOURCE_BASHRC
> uname output: Darwin patikoija.local 13.0.0 Darwin Kernel Version 13.0.0: Thu 
> Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/REL\
> EASE_X86_64 x86_64
> Machine Type: i386-apple-darwin13.0.0
> 
> Bash Version: 4.2
> Patch Level: 45
> Release Status: release
> 
> Description:
> 
>         An unquoted parameter expansion in a here string does not seem to 
> conform with my understanding of how
>         read works with a local IFS override. Personally observed in bash 
> 3.2.51, 4.1.2 as well. I first learned
>         of this possible bug via http://stackoverflow.com/q/20144593/1126841.
> 
> Repeat-By:
>         $ var="hello:world"
> 
>         # Case (1) I would expect "hello:world" in var1 if $var isn't split, 
> or "hello"
>         # if it is. World splitting seems to occur after var1 is set, which 
> doesn't
>         # seem to make sense.
>         $ IFS=: read var1 var2 <<< $var
>         $ echo "$var1"
>         hello world
> 
> $var is split on : and the expansion results in "hello world" which doesn't 
> contains a :, so var1 gets "hello world"
> but yeah, this is a bit of a grey zone
>  

Looking at the change log at http://tiswww.case.edu/php/chet/bash/CHANGES, I 
noticed item (jj) in the changes to bash 4.1 alpha:

    jj. Fixed a bug that caused variable expansion in here documents to look in
        any temporary environment.

And I can observe that between bash 3.2 and bash 4.1:

    bash-3.2 $ FOO=foo; FOO=bar cat <<< "$FOO"
    bar

    bash-4.1 $ FOO=foo; FOO=bar cat <<< "$FOO"
    foo


However, why is the new value of IFS applied to the expansion of $var, instead 
of the current? Shouldn't read get the literal string "hello:world" from the 
here string? And if $var is split, why doesn't this expression work the same as

    $ read var1 var2 <<< hello world

which is equivalent to

    $ read var1 var2 world <<< hello

The following works as expected, which implies that the new value of IFS is 
being applied prematurely, but the quotes protect the colon from causing 
splitting and being removed until "hello:world" can be properly split inside 
the read builtin.

    $ IFS=: read var1 var2 <<< "$var"


reply via email to

[Prev in Thread] Current Thread [Next in Thread]