bug-bash
[Top][All Lists]
Advanced

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

Re: updating shopt compat settings to include current version


From: Chet Ramey
Subject: Re: updating shopt compat settings to include current version
Date: Fri, 16 Oct 2015 11:37:53 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/15/15 5:30 PM, Mike Frysinger wrote:

> that assumes that behavior changes only once between versions.  pretty su
re
> we've seen changes where bash-3.2 did one thing, bash-4.3 did something e
lse,
> and versions in between did yet another thing.  i don't recall exact exam
ples
> off the top of my head, but i *feel* like it has happened :).

Oh, I'm sure it has.

> 
>>> 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 b
ug
>> 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.


>> 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.

> and it won't work when we updated to bash-4.2/4.3, or when you stop addin
g
> new compatXY options.

No, it really will.  Even if and when I take out the compatNN options,
unsetting BASH_COMPAT and setting it appropriately should do the trick.
If you want to make, say, bash-4.2 your minimum version, you will first
have to check ${BASH_VERSINFO[0]} and ${BASH_VERSINFO[1]} anyway to
identify bash versions that you want to reject.  Then you can use

unset BASH_COMPAT
shopt -u compat31 compat32 compat40 compat41
shopt -s compat42 2>/dev/null || :

to set shell_compatibility_level to 42 on bash versions >= bash-4.2.

(this needs the attached patch for bash-4.3 to fix a typo in shopt.def)

Chet

- -- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlYhGcUACgkQu1hp8GTqdKvjxQCdHKmE7Ouzi/ct/XjWqEjnDJrL
ahAAniFOB8rGodMhOZb8WSjTjOadlDf8
=lC3l
-----END PGP SIGNATURE-----

Attachment: shopt-compat42.patch
Description: Source code patch


reply via email to

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