Date: Wed, 1 Aug 2018 09:03:20 -0400
From: Greg Wooledge <wool...@eeg.ccf.org>
Message-ID: <20180801130320.wwmnw6ixxztih...@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
