Thorsten Glaser <tg <at> mirbsd.de> writes:
>
> Stephane Chazelas dixit:
>
> >$ IFS=:
> >$ set ${0+:foo:bar}
> >$ echo $#
> >2
>
> >Expected:
> >3
>
> You know, I *loathe* IFS word splitting.
>
> So whatb> after expanding it should beb> a field? And leading IFS from the
> replacement counts?
>
> Or is this about IFS WS vs. IFS NWS?
>
> tglase <at> tglase:~ $ mksh -c 'IFS=:; set ${0+:foo:bar}; echo $#'
> 2
> tglase <at> tglase:~ $ ksh93 -c 'IFS=:; set ${0+:foo:bar}; echo $#'
> 3
>
> tglase <at> tglase:~ $ mksh -c 'set ${0+ foo bar}; echo $#'
> 2
> tglase <at> tglase:~ $ ksh93 -c 'set ${0+ foo bar}; echo $#'
> 2
>
> I donb> have a testcase for the issue in the first place. (The issue
> was IFS-subst-2 and glob-trim-1 in the testsuite.)
>
> Anyway, thanks for reportingb>
> bye,
> //mirabilos
Sorry... I didn't realize it was so bad - I've always thought it was
handy... Still, if by *rule* you mean the POSIX spec it is this, I think:
...
Otherwise, the following rules shall be applied in sequence. The term " IFS
white space" is used to mean any sequence (zero or more instances) of white
space characters that are in the IFS value (for example, if IFS contains
<space>/ <comma>/ <tab>, any sequence of <space>s and <tab>s is considered
IFS white space)
a. IFS white space shall be ignored at the beginning and end of the input.
b. Each occurrence in the input of an IFS character that is not IFS white
space, along with any adjacent IFS white space, shall delimit a field, as
described previously.
c. Non-zero-length IFS white space shall delimit a field.
...
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag
_02_06_05
-mike
The difference is
