Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #11673

Re: updating shopt compat settings to include current version

From Chet Ramey <chet.ramey@case.edu>
Newsgroups gnu.bash.bug
Subject Re: updating shopt compat settings to include current version
Date 2015-10-16 11:37 -0400
Message-ID <mailman.460.1445009895.7904.bug-bash@gnu.org> (permalink)
References <20151015173433.GS4446@vapier.lan> <561FF051.8000001@case.edu> <20151015192704.GU4446@vapier.lan> <56200730.2060900@case.edu> <20151015213025.GW4446@vapier.lan>

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: updating shopt compat settings to include current version Chet Ramey <chet.ramey@case.edu> - 2015-10-16 11:37 -0400

csiph-web