bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More fun with IFS


From: Thorsten Glaser
Subject: Re: More fun with IFS
Date: Fri, 1 Mar 2013 11:49:37 +0000 (UTC)

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 address@hidden 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 address@hidden

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]