bug-bash
[Top][All Lists]
Advanced

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

Re: Unexpected word splitting on $* when IFS is unset


From: Chet Ramey
Subject: Re: Unexpected word splitting on $* when IFS is unset
Date: Wed, 21 Jun 2017 22:30:22 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1

On 6/21/17 6:01 PM, Kevin Brodsky wrote:
> On 21/06/2017 20:29, Chet Ramey wrote:
>> On 6/21/17 2:43 PM, Kevin Brodsky wrote:
>>
>>> That is also my reading of POSIX (and that's more or less what Bash's
>>> manpage says as well), but it doesn't seem to be the case (even in <=4.2):
>> That's a relatively new requirement.  The portion of the relevant sentence
>> that reads "initially producing one field for each positional parameter
>> that is set" is new as of issue 7 TC2. Without that, the splitting rules
>> for $* were effectively identical whether it was quoted or not quoted --
>> they were separated using the first character of $IFS. In a context where
>> they were not quoted and word splitting took place, this had the side
>> effect of splitting them in an unquoted context. When IFS is null, that
>> resulted in no splitting.
> 
> I have to admit I am now a bit confused as to what word splitting is
> supposed to happen when expanding $* (with the old and new spec). I
> thought it was very simple:
> * If quoted, there is no splitting whatsoever, and arguments are
> concatenated into a single string.
> * If not quoted, then each argument expands into a field, and all fields
> are split according to IFS (i.e. no splitting if IFS is null).
> 
> IIUC, before this sentence was added, then 'IFS=""; set -- a b; nb_args
> $*' should give 1, as no splitting occurs when IFS is null. However,
> this not the case on Bash 4.2.

Bash always had code to make unquoted $* essentially the same as unquoted
$@, with a lot of special-case code to cover various values of IFS and
figure out whether word splitting was going to take place at all.  That
was arguably a violation of the spec, and part of the discussion was
aimed at figuring that out.

However, not all shells were consistent in their interpretation of the
Posix rules. For instance, dash, which bills itself as being completely
Posix conformant, produces 1 for that case (and expands to "ab").  The
Bourne shell (SVR4.2 version) produces 1 as well, but expands it
differently ("a b"). Debian's posh produces the same results as the Bourne
shell. And so on.


> Do you have an example that results in a different number of arguments
> (after splitting) between Bash 4.2 and 4.3?

I don't, but you can look at the discussions around the time of the change
you identified. This is one:

http://lists.gnu.org/archive/html/bug-bash/2013-01/msg00167.html

There are some others on the Posix mailing list.

There was a lot of discussion back in March and April:

http://lists.gnu.org/archive/html/bug-bash/2017-03/msg00182.html
http://lists.gnu.org/archive/html/bug-bash/2017-04/msg00001.html

and a few others.

-- 
``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/



reply via email to

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