Dan Douglas dixit:
>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
[…]
>Consider for example if you ever implement "${@@Q}". Because of this behavior,
Hrm, you do have a point there. Now, how to do it for consistency…
re-reading the manual snippet:
* All positional parameters (except 0), i.e. $1, $2, $3, ...
If used outside of double quotes, parameters are separate words
(which are subjected to word splitting); if used within double
quotes, parameters are separated by the first character of the
IFS parameter (or the empty string if IFS is NULL).
@ Same as $*, unless it is used inside double quotes, in which case
a separate word is generated for each positional parameter. If
there are no positional parameters, no word is generated. $@ can
be used to access arguments, verbatim, without losing NULL argu-
ments or splitting arguments with spaces.
So this basically means, for “"$@"” generate
“one:::two three:::four” so it can be used verbatim.
*
Expands to the positional parameters, starting from one.
When the expansion occurs within a double-quoted string
(see [54]Double-Quotes ), it shall expand to a single
field with the value of each parameter separated by the
first character of the IFS variable, or by a <space> if
IFS is unset. If IFS is set to a null string, this is not
equivalent to unsetting it; its first character does not
exist, so the parameter values are concatenated.
This means “"$*"” needs to be “one:::two:three:::four”, and POSIX
doesn’t say anything about “$*” or “$@”… the manpage says “separate
words (which are subjected to word splitting)”, so I’d say we need
“one:::two:three:::four” for “$*” and thus also “$@”.
So basically, only “"$@"” needs to change to implement what comes
out of your point, and the other three cases need to stay the same.
Do you agree?
>> usually abstract everything eval into little functions of their
>> own and then just use those.
>I agree that's an excellent strategy. :)
;-)
bye,
//mirabilos
--
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (257 (276) bugs: 0 RC, 178 (192) I&N, 79 (84) M&W, 0 (0) F&P)
‣ src:dash (84 (98) bugs: 3 RC, 39 (43) I&N, 42 (52) M&W, 0 F&P)
‣ src:mksh (1 bug: 0 RC, 0 I&N, 1 M&W, 0 F&P)
http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?
