[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IFS boundary behaviour is not consistent passing arguments to a func
From: |
Chet Ramey |
Subject: |
Re: IFS boundary behaviour is not consistent passing arguments to a function for bash 4.3 or 4.4 . |
Date: |
Tue, 3 Oct 2017 16:13:11 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
On 10/2/17 11:26 PM, McCue, Glenn (SSC/SPC) wrote:
> The IFS behaves differently depending on how the command is structured.
> This is my test script. It demonstrates the behavior change between 3.2 and
> 4.[3|4].
>
> The function "doit" lists the individual arguments that it has received.
More or less; you need to add quoting.
> The function "doit" is called twice, each time setting IFS.
>
> The first time the function is called the arguments to "doit" are just listed
> in the function call.
>
> The second time the function "doit" is called the arguments are concatenated
> in a variable and the variable is used as the argument to the function.
It's clearer if you quote your variable references where you don't want
word splitting to happen ($argv1), but the basic change came between
bash-3.2 and bash-4.0, around January 2009. The bash-3.2 behavior was
incorrect.
IFS characters that aren't part of an expansion should not cause word
splitting. Bash-3.2 had a problem with `:', `=', and `~' (because of how
it did tilde expansion). If those characters are in $IFS, and they don't
result in tilde expansion, they should not cause word splitting.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/