Unexpected word splitting on $* when IFS is unset

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Unexpected word splitting on $* when IFS is unset

Kevin Brodsky
Hi,

When IFS is unset, unquoted $* undergoes word splitting as if IFS=' ',
and not the expected IFS=$' \t\n'. All the other unquoted mass
expansions ($@, array[*], array[@]) are word-split as if IFS=$'
\t\n'.For instance:

  nb_args() { echo $#; }
 
  set -- $'a\nb'
  unset IFS
 
  # Expected: 2, actual: 2
  nb_args $@
  # Expected: 2, actual: 1
  nb_args $*
 
  ar=("$@")
  # Expected: 2, actual: 2
  nb_args ${ar[*]}
  # Expected: 2, actual: 2
  nb_args ${ar[@]}

Note that this only occurs if IFS is *globally* unset. If made local and
then unset (as in f() { local IFS; unset IFS; ... }), $* is word-split
as expected.

This is a regression that appeared in 4.3 and is still present on devel
(bash-snap-20170616). A git bisect on devel shows that commit
1a81420a36fa (bash-20130125 snapshot) introduced this change. It seems
indeed that this commit is related to the handling of $* when IFS is
unset, but my knowledge of Bash's sources is too limited to tell what's
wrong with it :-)

Kevin

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Eduardo A. Bustamante López
On Tue, Jun 20, 2017 at 01:13:07AM +0100, Kevin Brodsky wrote:
[...]
> When IFS is unset, unquoted $* undergoes word splitting as if IFS=' ',
> and not the expected IFS=$' \t\n'. All the other unquoted mass
> This is a regression that appeared in 4.3 and is still present on devel
[...]

AFAICT, the following patch fixes this.

diff --git a/subst.c b/subst.c
index 3093309f..bf73a35f 100644
--- a/subst.c
+++ b/subst.c
@@ -10158,7 +10158,7 @@ finished_with_string:
  or we expanded "$@" with IFS null and we need to split the positional
  parameters into separate words. */
       if (split_on_spaces)
- list = list_string (istring, " ", 1); /* XXX quoted == 1? */
+ list = list_string (istring, " \t\n", 1); /* XXX quoted == 1? */
       /* If we have $@ (has_dollar_at != 0) and we are in a context where we
  don't want to split the result (W_NOSPLIT2), and we are not quoted,
  we have already separated the arguments with the first character of

The above code (`list_string' function call when split_on_spaces != 0)
seems to be executed when IFS is either unset or the empty string. The
comment above that block of code mentions that in either case, the
result should be "split on spaces", although it has a narrow definition
of space.

--
Eduardo Bustamante
https://dualbus.me/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Kevin Brodsky
On 20/06/2017 06:33, Eduardo A. Bustamante López wrote:

> On Tue, Jun 20, 2017 at 01:13:07AM +0100, Kevin Brodsky wrote:
> [...]
>> When IFS is unset, unquoted $* undergoes word splitting as if IFS=' ',
>> and not the expected IFS=$' \t\n'. All the other unquoted mass
>> This is a regression that appeared in 4.3 and is still present on devel
> [...]
>
> AFAICT, the following patch fixes this.
>
> diff --git a/subst.c b/subst.c
> index 3093309f..bf73a35f 100644
> --- a/subst.c
> +++ b/subst.c
> @@ -10158,7 +10158,7 @@ finished_with_string:
>   or we expanded "$@" with IFS null and we need to split the positional
>   parameters into separate words. */
>        if (split_on_spaces)
> - list = list_string (istring, " ", 1); /* XXX quoted == 1? */
> + list = list_string (istring, " \t\n", 1); /* XXX quoted == 1? */
>        /* If we have $@ (has_dollar_at != 0) and we are in a context where we
>   don't want to split the result (W_NOSPLIT2), and we are not quoted,
>   we have already separated the arguments with the first character of
>
> The above code (`list_string' function call when split_on_spaces != 0)
> seems to be executed when IFS is either unset or the empty string. The
> comment above that block of code mentions that in either case, the
> result should be "split on spaces", although it has a narrow definition
> of space.
>

The comments about "IFS either unset or null" confuse me, because word
splitting should behave very differently when IFS is null (there is no
word splitting at all, whereas unset IFS is equivalent to IFS=$' \t\n').
My tests show that the behaviour is as expected when IFS is null, so I'm
wondering if the comments match the actual behaviour.

Kevin

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Chet Ramey
In reply to this post by Kevin Brodsky
On 6/19/17 8:13 PM, Kevin Brodsky wrote:
> Hi,
>
> When IFS is unset, unquoted $* undergoes word splitting as if IFS=' ',
> and not the expected IFS=$' \t\n'. All the other unquoted mass
> expansions ($@, array[*], array[@]) are word-split as if IFS=$'
> \t\n'.

Thanks for the report. This will be fixed in the next devel branch push.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Chet Ramey
In reply to this post by Eduardo A. Bustamante López
On 6/20/17 1:33 AM, Eduardo A. Bustamante López wrote:
> On Tue, Jun 20, 2017 at 01:13:07AM +0100, Kevin Brodsky wrote:
> [...]
>> When IFS is unset, unquoted $* undergoes word splitting as if IFS=' ',
>> and not the expected IFS=$' \t\n'. All the other unquoted mass
>> This is a regression that appeared in 4.3 and is still present on devel
> [...]
>
> AFAICT, the following patch fixes this.

It's on the right track, but you still need to differentiate between the
cases where IFS is unset (in which case the positional parameters need to
be separated into individual words, and those individual words need to be
split on $' \t\n') and where IFS is null (in which case split_on_spaces is
used as an internal flag to satisfy the Posix requirement that $* expand
into separate words no matter what IFS is set to).

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Kevin Brodsky
On 21/06/2017 14:54, Chet Ramey wrote:

> On 6/20/17 1:33 AM, Eduardo A. Bustamante López wrote:
>> On Tue, Jun 20, 2017 at 01:13:07AM +0100, Kevin Brodsky wrote:
>> [...]
>>> When IFS is unset, unquoted $* undergoes word splitting as if IFS=' ',
>>> and not the expected IFS=$' \t\n'. All the other unquoted mass
>>> This is a regression that appeared in 4.3 and is still present on devel
>> [...]
>>
>> AFAICT, the following patch fixes this.
> It's on the right track, but you still need to differentiate between the
> cases where IFS is unset (in which case the positional parameters need to
> be separated into individual words, and those individual words need to be
> split on $' \t\n') and where IFS is null (in which case split_on_spaces is
> used as an internal flag to satisfy the Posix requirement that $* expand
> into separate words no matter what IFS is set to).

That is also my reading of POSIX (and that's more or less what Bash's
manpage says as well), but it doesn't seem to be the case (even in <=4.2):

  $ set -- 'a b'
  $ IFS=''
  $ nb_args $*
  1
  $ nb_args $@
  1

Am I missing something? Other shells like dash or zsh seem to behave
exactly in the same way, so I must be...

Kevin

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Chet Ramey
On 6/21/17 2:43 PM, Kevin Brodsky wrote:

> That is also my reading of POSIX (and that's more or less what Bash's
> manpage says as well), but it doesn't seem to be the case (even in <=4.2):

That's a relatively new requirement.  The portion of the relevant sentence
that reads "initially producing one field for each positional parameter
that is set" is new as of issue 7 TC2. Without that, the splitting rules
for $* were effectively identical whether it was quoted or not quoted --
they were separated using the first character of $IFS. In a context where
they were not quoted and word splitting took place, this had the side
effect of splitting them in an unquoted context. When IFS is null, that
resulted in no splitting.

There were long discussions on the Posix list about this starting in late
2014, resulting in Posix interp 888.

http://austingroupbugs.net/view.php?id=888

There are still some cases where I haven't completely made bash conform to
the new spec.

>
>   $ set -- 'a b'
>   $ IFS=''
>   $ nb_args $*
>   1
>   $ nb_args $@
>   1

This is a different situation: when IFS is null, there is no splitting. So
N fields are produced, one for each of N positional parameters, but they
are not split any further.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Kevin Brodsky
On 21/06/2017 20:29, Chet Ramey wrote:

> On 6/21/17 2:43 PM, Kevin Brodsky wrote:
>
>> That is also my reading of POSIX (and that's more or less what Bash's
>> manpage says as well), but it doesn't seem to be the case (even in <=4.2):
> That's a relatively new requirement.  The portion of the relevant sentence
> that reads "initially producing one field for each positional parameter
> that is set" is new as of issue 7 TC2. Without that, the splitting rules
> for $* were effectively identical whether it was quoted or not quoted --
> they were separated using the first character of $IFS. In a context where
> they were not quoted and word splitting took place, this had the side
> effect of splitting them in an unquoted context. When IFS is null, that
> resulted in no splitting.

I have to admit I am now a bit confused as to what word splitting is
supposed to happen when expanding $* (with the old and new spec). I
thought it was very simple:
* If quoted, there is no splitting whatsoever, and arguments are
concatenated into a single string.
* If not quoted, then each argument expands into a field, and all fields
are split according to IFS (i.e. no splitting if IFS is null).

IIUC, before this sentence was added, then 'IFS=""; set -- a b; nb_args
$*' should give 1, as no splitting occurs when IFS is null. However,
this not the case on Bash 4.2.

Do you have an example that results in a different number of arguments
(after splitting) between Bash 4.2 and 4.3?

> There were long discussions on the Posix list about this starting in late
> 2014, resulting in Posix interp 888.
>
> http://austingroupbugs.net/view.php?id=888
>
> There are still some cases where I haven't completely made bash conform to
> the new spec.
>
>>   $ set -- 'a b'
>>   $ IFS=''
>>   $ nb_args $*
>>   1
>>   $ nb_args $@
>>   1
> This is a different situation: when IFS is null, there is no splitting. So
> N fields are produced, one for each of N positional parameters, but they
> are not split any further.

Yes I realise now that this has to be true, as IFS being null means at
least that fields are not further split.

Kevin

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Chet Ramey
On 6/21/17 6:01 PM, Kevin Brodsky wrote:

> On 21/06/2017 20:29, Chet Ramey wrote:
>> On 6/21/17 2:43 PM, Kevin Brodsky wrote:
>>
>>> That is also my reading of POSIX (and that's more or less what Bash's
>>> manpage says as well), but it doesn't seem to be the case (even in <=4.2):
>> That's a relatively new requirement.  The portion of the relevant sentence
>> that reads "initially producing one field for each positional parameter
>> that is set" is new as of issue 7 TC2. Without that, the splitting rules
>> for $* were effectively identical whether it was quoted or not quoted --
>> they were separated using the first character of $IFS. In a context where
>> they were not quoted and word splitting took place, this had the side
>> effect of splitting them in an unquoted context. When IFS is null, that
>> resulted in no splitting.
>
> I have to admit I am now a bit confused as to what word splitting is
> supposed to happen when expanding $* (with the old and new spec). I
> thought it was very simple:
> * If quoted, there is no splitting whatsoever, and arguments are
> concatenated into a single string.
> * If not quoted, then each argument expands into a field, and all fields
> are split according to IFS (i.e. no splitting if IFS is null).
>
> IIUC, before this sentence was added, then 'IFS=""; set -- a b; nb_args
> $*' should give 1, as no splitting occurs when IFS is null. However,
> this not the case on Bash 4.2.

Bash always had code to make unquoted $* essentially the same as unquoted
$@, with a lot of special-case code to cover various values of IFS and
figure out whether word splitting was going to take place at all.  That
was arguably a violation of the spec, and part of the discussion was
aimed at figuring that out.

However, not all shells were consistent in their interpretation of the
Posix rules. For instance, dash, which bills itself as being completely
Posix conformant, produces 1 for that case (and expands to "ab").  The
Bourne shell (SVR4.2 version) produces 1 as well, but expands it
differently ("a b"). Debian's posh produces the same results as the Bourne
shell. And so on.


> Do you have an example that results in a different number of arguments
> (after splitting) between Bash 4.2 and 4.3?

I don't, but you can look at the discussions around the time of the change
you identified. This is one:

http://lists.gnu.org/archive/html/bug-bash/2013-01/msg00167.html

There are some others on the Posix mailing list.

There was a lot of discussion back in March and April:

http://lists.gnu.org/archive/html/bug-bash/2017-03/msg00182.html
http://lists.gnu.org/archive/html/bug-bash/2017-04/msg00001.html

and a few others.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Greg Wooledge
On Wed, Jun 21, 2017 at 10:30:22PM -0400, Chet Ramey wrote:
> However, not all shells were consistent in their interpretation of the
> Posix rules. For instance, dash, which bills itself as being completely
> Posix conformant, produces 1 for that case (and expands to "ab").  The
> Bourne shell (SVR4.2 version) produces 1 as well, but expands it
> differently ("a b"). Debian's posh produces the same results as the Bourne
> shell. And so on.

Oh, wow.  I didn't realize it was quite this bad.

$ dash
$ set -- a b
$ IFS=
$ args $*
1 args: <ab>
$ args $@
1 args: <ab>
$ args "$*"
1 args: <ab>
$ args "$@"
2 args: <a> <b>

$ ksh
$ set -- a b
$ IFS=
$ args $*
2 args: <a> <b>
$ args $@
2 args: <a> <b>
$ args "$*"
1 args: <ab>
$ args "$@"
2 args: <a> <b>

OK, going forward, I am officially considering any use of unquoted $*
or $@ in a script to be a BUG, an invocation of undefined behavior,
not acceptable, no excuses.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

DJ Mills
On Thu, Jun 22, 2017 at 7:51 AM, Greg Wooledge <[hidden email]> wrote:

> On Wed, Jun 21, 2017 at 10:30:22PM -0400, Chet Ramey wrote:
>
> OK, going forward, I am officially considering any use of unquoted $*
> or $@ in a script to be a BUG, an invocation of undefined behavior,
> not acceptable, no excuses.
>
>
I think this is pretty true of any unquoted expansion. You should be able
to get the
behavior you want without relying on wordsplitting
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Robert Elz
In reply to this post by Greg Wooledge
    Date:        Thu, 22 Jun 2017 07:51:12 -0400
    From:        Greg Wooledge <[hidden email]>
    Message-ID:  <[hidden email]>


  | $ dash
  | $ set -- a b
  | $ IFS=
  | $ args $*
  | 1 args: <ab>

That is simply broken.  Always has been, whatever mistakes were
in the wording posix used to use to try and explain how it works.

  | $ ksh
  | $ set -- a b
  | $ IFS=
  | $ args $*
  | 2 args: <a> <b>

This has always been the correct behaviour.  There is no field splitting
happening, but when unquoted, there's no joining happening either.
$* is just $1 $2 ... (for as many params as set) as separate words.

That is, if you knew how many words existed, and wrote it out in longhand
in the first place.  $* is just convenient when you don't know how many
params there are.

When quoted ("$*"), IFS[0] is used to turn the words into the string required,
when unquoted they are just words.  "$@" is the one slightly weird special
case, but only because it is defined to be "$1" "$2" ... (for as many
params as exist, including 0).

kre


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Greg Wooledge
On Fri, Jun 23, 2017 at 10:27:44PM +0700, Robert Elz wrote:
> $* is just $1 $2 ... (for as many params as set) as separate words.

That's what I always thought too, but if commonly used shells like
dash can't even agree on this, then I simply upgrade my response level
from "bad practice" to "completely wrong, don't ever do this" when
someone uses unquoted $* or $@.

It's not like it's ever *OK* to use them, really.  Now I just consider
it totally unacceptable instead of something that needs a stern warning.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Chet Ramey
In reply to this post by Robert Elz
On 6/23/17 11:27 AM, Robert Elz wrote:

>     Date:        Thu, 22 Jun 2017 07:51:12 -0400
>     From:        Greg Wooledge <[hidden email]>
>     Message-ID:  <[hidden email]>
>
>
>   | $ dash
>   | $ set -- a b
>   | $ IFS=
>   | $ args $*
>   | 1 args: <ab>
>
> That is simply broken.  Always has been, whatever mistakes were
> in the wording posix used to use to try and explain how it works.

The historical Bourne shell produces <a b>.  (Of course, the historical
Bourne shell didn't allow IFS to be unset, either, so it's not a valid
reference implementation.)  Some current shells, like posh, do the same
thing.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Robert Elz
In reply to this post by Greg Wooledge
    Date:        Fri, 23 Jun 2017 11:39:45 -0400
    From:        Greg Wooledge <[hidden email]>
    Message-ID:  <[hidden email]>

  | That's what I always thought too, but if commonly used shells like
  | dash can't even agree on this, then I simply upgrade my response level
  | from "bad practice" to "completely wrong, don't ever do this" when
  | someone uses unquoted $* or $@.

As Chet said in an earlier response, unquoted expansions are more often
bugs than not - but not always.  Anything that you attempt to apply as a
"one rule to govern them all" is going to be inappropriate sometimes.

Most of these issues only arise when IFS='' and while that's a perfectly
valid thing to do, and useful when appropriate, it is not particularly common.

In cases where IFS is not a null string, the broken implementations mostly
tend to work OK (sometimes perhaps only by a fluke), and even more work
properly if IFS has its default value or something similar, that is
where IFS[0] == ' ' to borrow an inappropriate way of writing it.

  | It's not like it's ever *OK* to use them, really.  Now I just consider
  | it totally unacceptable instead of something that needs a stern warning.

No, it is, and is required, if you have what is essentially a command in
the args, but which is yet to be pathname expanded, you cannot use quotes
or the pathname expansion doesn't happen, you can't do
        eval "$*"
as that will re-tokenise the input, and perhaps not split at the correct
places, there are times where only a bare $* (or $@ which is the same thing,
when unquoted, of course) will do.

These may be rare, but just saying "never do it" is too much.

kre

ps: I am not saying that there is not some bash private way of accomplishing
the same thing, I have no idea, but if there is, and it was used, that would
then make the script non-portable.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Eduardo A. Bustamante López
On Sat, Jun 24, 2017 at 09:35:34AM +0700, Robert Elz wrote:
[...]
> In cases where IFS is not a null string, the broken implementations mostly
> tend to work OK (sometimes perhaps only by a fluke), and even more work
> properly if IFS has its default value or something similar, that is
> where IFS[0] == ' ' to borrow an inappropriate way of writing it.
[...]
> These may be rare, but just saying "never do it" is too much.

Greg's advice is directed towards novice / intermediate shell script
programmers. I think we can all agree that the rules (and bugs) around
the expansion of $* are too complex. As a shell script writer trying to
make use $*, you'd have to verify that it works as expected across all
the shells (and even between different versions of the same shell).

IMO, it's easier to just document this kind of expansion as "undefined
behavior". Pretty much like we do with `errexit' already.

--
Eduardo Bustamante
https://dualbus.me/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Robert Elz
    Date:        Sat, 24 Jun 2017 07:59:25 -0500
    From:        Eduardo =?utf-8?Q?A=2E_Bustamante_L=C3=B3pez?= <[hidden email]>
    Message-ID:  <20170624125925.7vnb4kk35gh3obbk@debian>

  | I think we can all agree that the rules (and bugs) around
  | the expansion of $* are too complex.

The bugs in various implementations cause problems, yes, dealing with
someone else's mistakes (and especially doing it in a way that things
still work when the bugs get fixed) can be difficult.

But the rules, no, the rules for $* are actually trivial.

Unquoted, $* (or $@ which is identical) is exactly the same
as the sequence

        $1 $2 $3 ...

would be, if we knew in advance how many of those we should write
(which can be 0 of them of course.)

It is exactly that simple (ignoring implementation bugs.)

The only slight complication is when we have a$*b (for any a and b).
But that's just as simple really, "a" gets attached to the first of the
$n's produced (usually $1 unless $# is 0), and "b" gets attached to the
last.   So if $# is 3 we get
        a$1 $2 $3b
(with the obvious extension to bigger $# values).  For $# = 2 it
is just a$1 $2b , for $# = 1, a$1b and for $# = 0 we get just ab

No-one has any problem understanding what $1 means or what a
sequence of args means, and $* just combines those two.

When quoted, $@ (ie: "$@") is just as simple, except each $n generated
is quoted "$1" "$2" "$3" (and the combining rule for adjacent text is
the same as above.)   And just as above $# can be 0, and nothing (assuming
no attached text) is generated.

All that is left is "$*" which just produces "$1x$2x$3x" for as many
args that exist, where 'x' is the first char of IFS (and may be nothing
at all).   In this one the "" string is always generated, even when $# is 0,
it is just empty then.

kre


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Eduardo A. Bustamante López
On Sat, Jun 24, 2017 at 09:10:34PM +0700, Robert Elz wrote:
[...]

> The bugs in various implementations cause problems, yes, dealing with
> someone else's mistakes (and especially doing it in a way that things
> still work when the bugs get fixed) can be difficult.
>
> But the rules, no, the rules for $* are actually trivial.
>
> Unquoted, $* (or $@ which is identical) is exactly the same
> as the sequence
>
> $1 $2 $3 ...
>
> would be, if we knew in advance how many of those we should write
> (which can be 0 of them of course.)
>
> It is exactly that simple (ignoring implementation bugs.)

I think we are arguing about different things. My point (and which I
think is Greg's point) is that we should start recommending shell script
writers to stay away from the unquoted expansions of $* and $@.

Yes, the POSIX rules might be "trivial", but the actual implementations
are not, and shell script programmers care about running their scripts
on real implementations.

--
Eduardo Bustamante
https://dualbus.me/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Unexpected word splitting on $* when IFS is unset

Chet Ramey
In reply to this post by Robert Elz
On 6/23/17 10:35 PM, Robert Elz wrote:

>     Date:        Fri, 23 Jun 2017 11:39:45 -0400
>     From:        Greg Wooledge <[hidden email]>
>     Message-ID:  <[hidden email]>
>
>   | That's what I always thought too, but if commonly used shells like
>   | dash can't even agree on this, then I simply upgrade my response level
>   | from "bad practice" to "completely wrong, don't ever do this" when
>   | someone uses unquoted $* or $@.
>
> As Chet said in an earlier response, unquoted expansions are more often
> bugs than not - but not always.  Anything that you attempt to apply as a
> "one rule to govern them all" is going to be inappropriate sometimes.

In the vast majority of cases, people really desire the effects of "$@"
and should just use that.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    [hidden email]    http://cnswww.cns.cwru.edu/~chet/

Loading...