Re: Array parameter expansion with non-space-IFS on bash-3/4
On Nov 27, 3:47 pm, Freddy Vulto wrote:
> I noticed different behaviour between bash-3 and bash-4 when
> performing parameter expansion on an array with IFS set to a non-space
> value. For example, on bash-3.2.39, I get:
>
> $ bash -c 'IFS=:; printf "<%s>\n" "${@/q}"' x a b
>
>
> Whereas on bash-4.0.33, I get:
>
> $ bash -c 'IFS=:; printf "<%s>\n" "${@/q}"' x a b
>
>
>
> Bash-4 seems to give the desired result (leave the array intact), but
> it's a bug on bash-3?
>
> Regards,
>
> Freddy Vultohttp://fvue.nl
It seems to be a combination of IFS and pattern substitution. There's
another difference shown below with an intact IFS, but referring to a
string as an array.
Using this script:
#!/bin/bash
v=(a b c)
w="d e f"
printf "<%s>\n" "$...@]/q}"
IFS=X
printf "<%s>\n" "$...@]/q}"
In Bash 4.0.33(1)-release I get:
In Bash 3.2.49(23)-release I get:
Other combinations of array vs. string, changing IFS or not, and/or
not using pattern substitution produce the same results in the two
versions.
Dennis
sysadmins: visit serverfault.com
Re: ESC SPC please
On Sun, 29 Nov 2009, jida...@jidanni.org wrote: PG> maybe try the following macro: PG> bind '"\M- ":"\M-\\ "' Sorry, that doesn't work on the command line or .inputrc. No effect. ah, it works for me.
Re: bash 3.2.39 -- race condition
Chet Ramey wrote:
Douglas Moyes wrote:
I nearly brought down a server today.
# alias d="perl-script "
# d() {
# perl-script $1 |grep something|cut -d ' ' -f 3
# }
# d something
. . CRASH
turns out bash went into a loop calling d over and over again, which
resulted in thousands of grep, bash, and -d processes being executed. It
wasn't pretty.
You defined `perl-script' as a recursive function (alias expansion is
performed when a function is defined) and called it. I'm not surprised
at the result.
Chet
So... what you're saying is that this:
# alias d="dh-machine "
# d() {
# dh-machine $1 |grep something|cut -d ' ' -f 3
# }
became this:
# alias d="dh-machine "
# dh-machine() {
# dh-machine $1 |grep something|cut -d ' ' -f 3
# }
And bash didn't treat d() as a a unique identifier because it tokenized
d and (), then expanded 'd' as an alias. Okay, I see how that makes the
interpreter simpler, but it's not that intuitive and most likely would
always be an undesired effect. It would be more intuitive if "() {"
ignored any previous definition of .
Re: Array parameter expansion with non-space-IFS on bash-3/4
DennisW wrote:
> On Nov 27, 3:47 pm, Freddy Vulto wrote:
>> I noticed different behaviour between bash-3 and bash-4 when
>> performing parameter expansion on an array with IFS set to a non-space
>> value. For example, on bash-3.2.39, I get:
>>
>> $ bash -c 'IFS=:; printf "<%s>\n" "${@/q}"' x a b
>>
>>
>> Whereas on bash-4.0.33, I get:
>>
>> $ bash -c 'IFS=:; printf "<%s>\n" "${@/q}"' x a b
>>
>>
>>
>> Bash-4 seems to give the desired result (leave the array intact), but
>> it's a bug on bash-3?
>>
>> Regards,
>>
>> Freddy Vultohttp://fvue.nl
>
> It seems to be a combination of IFS and pattern substitution.
It was a bug in bash-3.2, fixed in bash-4.0.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
