Re: More fun with IFS

[Dan Douglas]

On Wednesday, February 27, 2013 01:31:58 PM Thorsten Glaser wrote:
> Why whitespace? $IFS certainly contains none. And the usual
> insertion rules all specify the first character of $IFS and
> specify what to do if $IFS is empty or unset (which it isn’t
> in these examples).

Well, ok then. I'm just nitpicking here. I think this makes sense because it 
distinguishes between $@ and $* when assigning to a scalar, so that the end 
result of $@ is always space-separated, as spaces delimit words during command 
parsing. Your way would make more sense to me if this were the Bourne shell 
where IFS is in charge of both the initial argument splitting and field 
splitting. In this case though it seems strange to use IFS to represent 
separate words.

Consider for example if you ever implement "${@@Q}". Because of this behavior, 
the integrity of the result can only be guaranteed with a default IFS during 
assignment. This can be demonstrated with zsh which implements the same 
expansion (with different syntax) and uses the same assignment rules as mksh.

 $ zsh -s <<\EOF
emulate ksh
typeset -a cmd
cmd=(echo w:x y:z)
IFS=: x=${(q)cmd[@]} # Now we're in trouble
typeset -p x
unset -v IFS # Different problem whether or not we go back to default.
eval $x
EOF

typeset x=echo:w:x:y:z
zsh:1: command not found: echo:w:x:y:z

> Yeah, of course, it’s the only way to do some things… I personally
> usually abstract everything eval into little functions of their
> own and then just use those.
>

I agree that's an excellent strategy. :)

-- 
Dan Douglas