[Top][All Lists]

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

Re: updating shopt compat settings to include current version

From: Mike Frysinger
Subject: Re: updating shopt compat settings to include current version
Date: Tue, 20 Oct 2015 14:49:23 -0400

On 16 Oct 2015 11:37, Chet Ramey wrote:
> On 10/15/15 5:30 PM, Mike Frysinger wrote:
> >>> the bash compat feature seems to address this nicely: our standard says
> >>> we should use bash-3.2, so we set the compat level to that, and then we
> >>> have much stronger confidence in newer versions not breaking, or people
> >>> adding code that only works on newer versions.
> >>
> >> You should approach this with caution.  I'm sure there are changes and bug
> >> fixes that introduce incompatible behavior that are not addressed by the
> >> compatNN variables.  I guess as long as it doesn't bite you, you're ok.
> > 
> > right.  we're OK with reporting & getting those fixed.
> Sometimes they're not going to be `fixed'.  Many times those are really
> bug fixes or fixes for greater consistency or compatibility.

we're not looking for perfect.  we understand there's no way to guarantee that
(short of keeping around an old version of bash and never upgrading it).  the
point is to improve the status quo.

> >> I mean, in theory, it's simple to do that:
> >>
> >> unset BASH_COMPAT
> >> shopt -u compat31
> >> command shopt -s compat32 2>/dev/null
> > 
> > ... but that doesn't work in bash-3.2:
> > $ bash-3.2 -c 'shopt -s compat32'
> > bash-3.2: line 0: shopt: compat32: invalid shell option name
> No, it really does.  That's why I redirected the output to /dev/null.  If
> you run with `set -e' enabled, you can follow it with `|| :'.
> Running those commands leaves shell_compatibility_level == 32 on all
> existing versions of bash >= bash-3.2.   The trick is that on bash-3.2,
> unsetting compat31 sets the shell compatibility level to 32, so the
> failed attempt to set compat32 doesn't make a difference.

my point was to have a code snippet that works for any bash version and a
shifting base.  we've established that you aren't interested in adding more
compat flags, and that BASH_COMPAT is not useful for error checking.  fine,
we'll just add some ad-hoc checks ourselves using the existing bash version
variables.  that isn't supposed to sound petulant, just accepting of the
reality of the situation.

Attachment: signature.asc
Description: Digital signature

reply via email to

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