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

[Robert Elz]

    Date:        Fri, 23 Jun 2017 11:39:45 -0400
    From:        Greg Wooledge <wooledg@eeg.ccf.org>
    Message-ID:  <20170623153945.GA4028@eeg.ccf.org>

  | 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.