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
