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 > > 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 there > 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.
by this logic, why does BASH_COMPAT accept '4.3' but there is no compat43 ?
seems like your argument is inconsistent.
> > 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 this
> 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. 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. 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). 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.
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. obviously it's not a
perfect soultion (there isn't really a scalable one), but it's still a
lot better than what we have today.
> > instead we have to probe the active version ourselves:
> > if ! shopt -s compat43 ; then
> > if [[ ${BASH_VERSINFO[0]} -ne "4" || ${BASH_VERSINFO[1]} -ne
> > "3" ]] ; t
> hen
> > echo ...
> > exit 1
> > fi
> > fi
> >
> > 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 really
> 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.
> > - 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.
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.
> > - 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.
$ bash-4.3
$ BASH_COMPAT=5.0
bash-4.3: BASH_COMPAT: 5.0: compatibility value out of range
$ bash-3.2
$ BASH_COMPAT=5.0
$ shopt -s compat50
bash-3.2: shopt: compat50: invalid shell option name
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.
-mike
signature.asc
Description: Digital signature
