bug-bash
[Top][All Lists]
Advanced

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

Re: Trouble testing for bash


From: Paul Eggert
Subject: Re: Trouble testing for bash
Date: Tue, 23 Oct 2001 21:57:55 -0700 (PDT)

> From: address@hidden (Niels M├Âller)
> Date: 23 Oct 2001 23:11:53 +0200
> 
> I think that changing bash to *not* set BASH in its compatibility
> mode,

That makes sense.  After all, POSIX says that

  BASH=/bin/bash sh -c 'echo $BASH'

should output "/bin/bash".  If Bash doesn't do that, it's not being
compatible with POSIX.

The fact that Bash acts differently when invoked as "sh" doesn't seem
to be documented in the Bash reference manual.  Also, it runs contrary
the GNU coding standards, which say "Please don't make the behavior of
a utility depend on the name used to invoke it."
<http://www.gnu.org/prep/standards_16.html#SEC16>

Perhaps there are historical reasons for this discrepancy, but they
ought to be documented; if not, Bash should get fixed.  For example,
Bash's "act_like_sh" behavior could depend solely on POSIXLY_CORRECT;
that would fix the discrepancy with the GNU coding standards.  It's
confusing to have two different things affect Bash's
standard-conformance (in different ways, apparently).

> and adding some workaround in autoconf (as it will take a long time
> until all bashes out there are upgraded)

You've run into an unfortunate combination of features.  I would work
around the problem by not using variable names that Bash happens to
reserve.  Sorry, but I think that's the best you can do.  (Autoconf
never uses the variable BASH, so it doesn't need the workaround itself.)

There are lots of other troublesome variable names that are reserved
by some shell or another (e.g. LINENO), and I don't think Autoconf can
work around them all.  At best we could try to catalog them and have
Autoconf warn if someone tries to use them.



reply via email to

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