bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: Bug#519165: bash 4 regression]


From: Chet Ramey
Subject: Re: [Fwd: Bug#519165: bash 4 regression]
Date: Fri, 03 Jul 2009 13:52:48 -0400
User-agent: Thunderbird 2.0.0.22 (Macintosh/20090605)

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 <madduck@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    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]