Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #11673
| 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> |
[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
Re: updating shopt compat settings to include current version Chet Ramey <chet.ramey@case.edu> - 2015-10-16 11:37 -0400
csiph-web