Matthias Klose wrote: > wouldn't this changed behaviour warrent a compatibility switch?
I'm going to do what the Posix group decides. Read http://lists.gnu.org/archive/html/bug-bash/2009-06/msg00107.html for a summary; portions of which I will reproduce below. (And the line that got munged in the bug-bash archives noted the inconsistency of bash-3.2 not exiting on $@ but exiting on the variant with braces.) > Subject: Bug#519165: bash 4 regression > From: martin f krafft <madd...@debian.org> > Date: Wed, 29 Apr 2009 12:19:08 +0200 > > $@ and $* are special, and not really variables. In any context > where there are positional parameters, they are set. This is true. They're not variables; they are positional parameters. > 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. There is, in fact a de facto standard, but the bash4 behavior is what the Bourne and Korn shells have always done. In fact, the only way Martin's statement is true is if "all other shells" means "dash", since that's the only other shell I found that doesn't apply set -u to $@ and $*. A partial list of shells that honor set -u when expanding $@ and $*: bash4 all versions of the bourne shell from v7 to svr4.2 all versions of the korn shell pdksh and variants like mksh and posh ash and its descendents except dash > 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. Creative, but irrelevant. The key was the "variables" language in the Posix description of `set -u', which invalidates historical behavior. $@ and $* are not variables. > 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. Beautiful language, but incorrect. The current bash4 behavior is not an "eclectic interpretation," but consistent with how shells have historically behaved. > I am thus marking this bug grave as it breaks a lot of existing > scripts. Can't win, can you? :-) When bash does something different from historical shell behavior, it either gets slammed because the difference exists or because people write scripts that depend on the difference. :-) Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
