# justification: breaks plenty other packages,
# and if only by way of #522255
severity 518752 grave
tags 518752 upstream confirmed
thanks
also sprach Andreas Metzler <ametzler@downhill.at.eu.org> [2009.03.08.1442
+0100]:
> d. Fixed a bug that caused expansions of $@ and $* to not exit
> the shell if the -u option was enabled and there were no
> posititional parameters.
[…]
> Personally I do not think this as clear cut as upstream's
> changelog says. set -u should cause a failure if you try to
> "expand a variable that is not set". However afaict it is not
> clear that the absence of positional parameters should cause the
> shell to "not set" $@. The standard just says "If there are no
> positional parameters, the expansion of '@' shall generate zero
> fields, even when '@' is double-quoted." So there is
> special-casing, "$@" expands to nul, not the empty string.
$@ and $* are special, and not really variables. In any context
where there are positional parameters, they are set. If there are
zero positional parameters (but the context is such that positional
parameters exist, e.g. a function, script, or after set has been
called; read: always), then their values is nothing (for $@) or the
empty string (for $*).
Maybe the standard is not clear, but all other shells do it the way
bash has always done it, so I don't see a need to deviate from that
path. There are de-facto standard, after all.
On the other hand, Goswin von Brederlow points out that the standard
is perfectly clear: "'@' shall generate zero fields" does not
suggest "shall fail to expand". Some might say it pretty clearly
says that it must not fail to expand, ever. Put differently, this
means that those two "variables" can never be undefined in the sense
of set -u.
We can debate this issue ad mortem infinitumque (but let's not).
Fact is that this is a regression, which upstream camouflaged as
a bug fix, when instead there should have been a deprecation period.
Expecting everyone to change their scripts to work around bash's
eclectic interpretation of $@/$* is not the way forward.
I am thus marking this bug grave as it breaks a lot of existing
scripts.
> With posh replacing "$@" with "${@:+}" works as a workaround, however
> bash even then throws the error. - Is this a bug in bash?
The standard defines $@ specially (see above), and given the
following example:
madduck@piper:~$ f() { echo $#; }; g() { f "$@"; }; h() { f "${@:-}"; }; g; h
0
1
this does not help, since both, ${@:-} and ${@:+}, expand to at
least one field (never to zero), and you would need a workaround
using [ $# -eq 0 ], which is just unacceptable at the scale we're
talking about.
This all just goes to show that $@ (and $*) are special and must not
be treated like any plain variable. Specifically, they are *never
undefined*.
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
--- End Message ---