Re: updating shopt compat settings to include current version

[Linda Walsh]

Mike Frysinger wrote:

> 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.
----
	But it doesn't do that.  It isn't like perl's "use 6.5.18" to say 
"enabled all "6.5.18" features and and those found in all previous versions.
And the, or "no 6.5.8" "disallow all versions @6.5.8 and earlier.  

        The compat's were put in for specific instances where changed behavior
was enough of a bother that people wanted the old behavior back.  But if you,
say "shopt -s bash10 (if it existed)", it wouldn't prevent people from using
newer features that didn't cause a backwards compat issue (say 
declare -l lowcase_this, or arrays)  and several incompat behaviors were NOT
given any option for future usage -- when "-e" changed from 'simple cmd' to
'complex cmd|function|builtin', there was no --compat_e_useful to go back to.


> but when bash changes
> behavior on us (there are a variety of examples between 3.2 and 4.3), some
> ebuilds break because they expected bash 3.2 behavior but got something
> else.  
----
        I feel your pain... on so many projects...

On one project, they boast that the project is a "do-acracy", and that
those who "do" rule (ignoring the fact that they don't just let anyone
'do', so are shut out of new design (systemd multiple previous
systems and backwards compat being deliberately removed to force people
to the new systems).  Another project had it's "cabal" that others
should feel "gratitude" toward for making all those hard development
decisions for them -- *cough*... while shutting out non-insider input.

> 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).  
---
        Yep... I don't have the pckcnt, but I have similar issues in
multiple products that I have to re-architect for a working system w/each
new release.  

> 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.
-----
        Oh please do to others what I don't like being done to me!

        WHAT?  Don't you think that would break scripts that need
those options (BTW - so far I don't have any 'compat<oldver>' shopt's
set in my script, cuz I know they are likely temporary.


> seems like bash should be ignoring BASH_COMPAT when creating a new shell ?
> then again, i don't think it does that for other BASH env vars, so probably
> don't want to special case it.  same as things like POSIXLY_CORRECT.
---
        ???  Example? remember, mostly outside of chet's control is the
fact that posixly_correct is a **changing** standard.
with each new POSIX release. (compatxy is used to mitigate 'some' of
those changes)

> if you set the variable in older versions, then bash silently accepts it.
> shopt is not silent at all.
> $ bash-4.3
> $ BASH_COMPAT=5.0
> bash-4.3: BASH_COMPAT: 5.0: compatibility value out of range
---
	So are you seem to be saying that a "set -s compat42" 
ought to be introduced that emulates, in previous versions
behavior w/r/t BASH_COMPAT?  ;-?


> 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 with the 
> various changes in compat selection.
----
Why do you think 'configure' scripts take so long... ;-)