wouldn't this changed behaviour warrent a compatibility switch?
--- Begin Message ---# justification: breaks plenty other packages, # and if only by way of #522255 severity 518752 grave tags 518752 upstream confirmed thanksalso sprach Andreas Metzler <ametz...@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: madd...@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 <madd...@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 systemsdigital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
--- End Message ---