Re: updating shopt compat settings to include current version

[Chet Ramey]

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

On 10/15/15 3:27 PM, Mike Frysinger wrote:
> On 15 Oct 2015 14:28, Chet Ramey wrote:
>> On 10/15/15 1:34 PM, Mike Frysinger wrote:
>>> with bash-4.0, new compat options were introduced:
>>>     shopt -s compat32

You've picked the story up in the middle.  bash-3.2 had compat31.

>>> and with bash-4.3, a variable was added:
>>>     export BASH_COMPAT=3.2
>>>
>>> but things get a little weird when you want to set the compat level to
>>> the current version:
>>
>> Unsetting all the compatNN variables and BASH_COMPAT does this.  In fact
,
>> even if you set, say, compat43, then set and unset BASH_COMPAT, the
>> compatibility level is set to the current version (which means that ther
e
>> is no compatibility level -- it's an indication of *backwards*
>> compatibility, after all).
> 
> it's an indication of the standard you want to use.  the current standard
 is
> just a different level to be selected.

No, not really.  That was not the intent.  The absence of backwards
compatibility options, as limited as they are, indicates that you want
to use the current version.

> by this logic, why does BASH_COMPAT accept '4.3' but there is no compat43
 ?
> seems like your argument is inconsistent.

Maybe, in retrospect, it's a bug.  Bugs can be fixed.

>>> we're interested in this in Gentoo because we want to set the current
>>> shell compat level to a min version even if that version is the active
>>> one.  ideally it'd be:
>>>     if ! shopt -s compat43 ; then
>>>             echo "error: >=bash-4.3 required, but ${BASH_VERSION} found" >&2
>>>             exit 1
>>>     fi
>>
>> What practical use does this have?  What does Gentoo intend to do with t
his
>> requirement?
> 
> our build environment relies heavily on bash.  in our ebuild standard, we
> declare the min version of bash that is supported (3.2 currently).  this
> way we don't have people using features found only in newer versions and
> breaking on systems with older versions of bash.

Wow.  How many systems have bash-3.2?  It is ten years old, after all.  Do
you build and support new packages for old systems running bash-3.2?

>  but when bash changes
> behavior on us (there are a variety of examples between 3.2 and 4.3), som
e
> ebuilds break because they expected bash 3.2 behavior but got something
> else.  so every bash release ends up triggering a fire drill where we try
> to weed out all the common issues (we have ~20k packages, and many have
> multiple versions).

Do you ever do any of this work with the alpha and beta versions?  It
seems like there are months there when you could be addressing these
issues.

>  even then, for a while people introduce bugs since
> they're running the new version only (or old version), and people notice
> because things break.  then it settles down once everyone has moved to
> the same version.  but i'm sure even today we add code that does not work
> under bash-3.2 (or some version between then and now), but most people do
> not notice, and those who do aren't guaranteed to file bugs.

You could always just run bash-3.2 against your ebuild system, or run the
collection of scripts under bash-3.2, to test whether or not it works.

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




>>> the BASH_COMPAT variable isn't as useful:
>>
>> I disagree.  In fact, in a future version I'm going to stop introducing 
new
>> compatNN options in favor of looking at the value of BASH_COMPAT.  I rea
lly
>> don't want to end up with 12 compatNN options.
> 
> why not just do it now then and delete all the existing ones ?  seems
> better to cut people off asap rather than get them used to using it.

The compatNN variables have been there for 10 years.  If people are going
to get used to using them, it's already happened.  The right place to do
that is at a major version boundary.

> 
>>>  - possible to accidentally export and impact other shell scripts
>>
>> It's kind of flip to say, but don't do that.
> 
> here's this sharp porcupine.  pet it, but not really.

Here's this sharp porcupine.  Understand what it is and treat it
appropriately.

> 
> seems like bash should be ignoring BASH_COMPAT when creating a new shell 
?

No, you should be able to use something like

BASH_COMPAT=3.2 ./bash

to create a shell with the compatibility level set to 32.  You can't now,
but that's functionality that should be added.

> then again, i don't think it does that for other BASH env vars, so probab
ly
> don't want to special case it.  same as things like POSIXLY_CORRECT.
> 
>>>  - doesn't fail for <bash-4.3 versions
>>
>> What?
> 
> if you set the variable in older versions, then bash silently accepts it.
> shopt is not silent at all.

Ah.  Well, sure.  Only bash-4.3 assigns any meaning to it.

> at any rate, it looks like the intention is to not do what we want, so we
'll
> have to explicitly check the BASH_VERSINFO ourselves up front and deal wi
th the
> various changes in compat selection.

Is it just the ebuild system or do you want to make sure every shell sets
compat32?

I mean, in theory, it's simple to do that:

unset BASH_COMPAT
shopt -u compat31
command shopt -s compat32 2>/dev/null

(you don't really need the `command').  Even on bash-3.2, that leaves
shell_compatibility_level=32

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

iEYEARECAAYFAlYgByEACgkQu1hp8GTqdKuRrgCaA2TvzUJUMhCPwVT4VruFm+rH
OAEAn3hoL6HwEpUCIioH7Wh1+wMhPGNE
=aPCQ
-----END PGP SIGNATURE-----