bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: updating shopt compat settings to include current version


From: Chet Ramey
Subject: Re: updating shopt compat settings to include current version
Date: Thu, 15 Oct 2015 14:28:33 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

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

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

If you really want to do it, though, you can:

BASH_COMPAT=${BASH_VERSINFO[0]}.${BASH_VERSINFO[1]}


>       $ echo $BASH_VERSION
>       4.3.42(1)-release
>       $ shopt -s compat43
>       bash: shopt: compat43: invalid shell option name
>       $ export BASH_COMPAT=4.3
>       <no error as DEFAULT_COMPAT_LEVEL is 43>
> 
> 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?

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

>  - possible to accidentally export and impact other shell scripts

It's kind of flip to say, but don't do that.

>  - doesn't fail for <bash-4.3 versions

What?

>  - when set to a bad value, $? is set to 0

Hmmm...then you don't think it's useful to print an error message in
this case?  Strictly speaking, the assignment should not fail -- the
value was assigned successfully, and the warning indicates that the
assignment may not have the intended effect.  Let me take a look at that
and see what I can do, though.

>  - need to capture & test stderr
> which means you end up with:
>       if ([[ -n $( (BASH_COMPAT=4.3) 2>&1 ) ]] ||
>           [[ ${BASH_VERSINFO[0]} -lt 4 ]] ||
>           [[ ${BASH_VERSINFO[0]} -eq 4 && ${BASH_VERSINFO[1]} -lt 3 ]]) ; then
>               echo ...
>               exit 1
>       fi
>       BASH_COMPAT=4.3
> 
> so my request is simple: can we have compatXY added for the current versi
on ?
> so in the upcoming bash-4.4 release, get a compat44 option added.

This runs counter to the intent of the options.

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

iEYEARECAAYFAlYf8EcACgkQu1hp8GTqdKsjNACdHU5aLPF3l08+wYJ/EWWKa/FH
xbEAoIkurQCIIKhw0psmBvWsjB+To5lZ
=jxes
-----END PGP SIGNATURE-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]