Re: SH_WORD_SPLIT, $* and null IFS

[Paul Mertz <paul.mertz6@xxxxxxxxx>]

Thank you for your detailed answer Bart,

I'm puzzled by what you mean about "will not care about the IFS".  (Skip
> past the examples for me figuring out what you probably mean.)
>

What I meant by "$* don't care about the ifs" is that the IFS is not
expected to be involved in the joining of parameters when using $* not
enclosed by double quotes (it is however obviously used when expanding each
parameters).

Can you post a specific example showing what you're experiencing?


I should have started by that :)

If we take a look to the following code:
------
host# IFS=
host# set - "a b" "c   d" e$'\0'f 'gxh'
host# print -l $*
a b
c   d
ef
gxh
host# setopt sh_wordsplit
host# print -l $*
a bc   defgxh
-----

We can see that a null IFS (a unset IFS will not trigger this) is actually
changing the behavior of $* when sh_wordsplit is set: parameters are all
joined together. But as far I as know, this kind of joining is only expected
to happen when using "$*" not $*. It's counter-intuitive at best.


>
> Rule 10 plus possibly that last part about rule 22 being skipped when
> single words are not required is what causes the behavior on joining.
> When IFS is empty, the words are joined at step 10 but NOT split again
> at 17, and rule 22 doesn't matter.  When IFS is non-empty, the words
> are joined at 10, then split at 17, and then NOT joined at 22.



> My recollection (which may be wrong) is that POSIX leaves unspecified
> (or makes implementation-defined) the order in which this occurs, and
> requires that the double quotes be used to get defined behavior.
>

This could indeed explain why for example bash and ksh, which are splitting
words by default, do react in the "right" way, while dash and maybe other
shell have this (highly) unexpected behavior... I just found strange that
it's apparently not documented anywhere... But i guess it's not that
important...

Anyway, thank you for your time,

Paul