Re: Unquoted array slice ${a[@]:0} expands to just one word if IFS doesn't have a space

[Robert Elz]

    Date:        Wed, 1 Aug 2018 09:03:20 -0400
    From:        Greg Wooledge <wooledg@eeg.ccf.org>
    Message-ID:  <20180801130320.wwmnw6ixxztihj3i@eeg.ccf.org>

  | "$@" expands to a list of words, and "$*" expands to a single string
  | with an optional single-character delimiter inserted between substrings.
  | Those are the only two options you've got.

No they aren't, the third is the unquoted form (where $@ and $* are
the same, so we don't get 4 cases).

  | What's the intent of a script that uses unquoted $@ or $*?

Either (or both) of field splitting of the args, or filename expansion.

As in
        set -- '*.c' '*.h'
where
        echo $@
is quite different to
        echo "$@"
which is (a little) different to
        echo "$*"
(in that the latter separates $1 from $2 by the first char of IFS
whereas the previous one uses a space).   Of course if the
command were not "echo" they would be more different.

Please get off your "always quote" hobbyhorse.   In many situations
that is good advice, but not always.

  |  What did the script's author think was going to happen?

        [jinx]$ set -- 'a b' c
        [jinx]$ echo $#
        2
        [jinx]$ set -- $@
        [jinx]$ echo $#
        3

That is what I expect, and want, to happen.   In this case, field splitting,
just as if I had written

        set -- $1 $2

There's no special case, or magic, involved when $@ or $* is used instead
of listing the args separately (except the shell works out how many args
need be listed, instead of me...)

  | If it's one of the two cases above,

It isn't.

  | then the missing quotes are simply a bug in the script.

Indeed, it would be.    But as it isn't...

  | If it's something else, then I'd be interested in hearing it.

Is your interest satisfied now?

  | I don't speak for Chet on any of these issues.  He may feel an obligation
  | to fix bash if he perceives the behavior as a bug.  That's independent
  | of whether a script writer should actually USE such syntax.

It is indeed, and as the case in question is a private bash (ksh too??) 
extension, bash (aka Chet) gets to decide what the behaviour should be.

But for the simple cases ($@ and $*) posix says what should happen,
users are entitled to expect that (and as far as I can tell, with bash,
they get that) and also to use it, if that's what they need to happen.

kre