Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!usenet.stanford.edu!not-for-mail
From: Chet Ramey <chet.ramey@case.edu>
Newsgroups: gnu.bash.bug
Subject: Re: updating shopt compat settings to include current version
Date: Thu, 15 Oct 2015 14:28:33 -0400
Lines: 101
Approved: bug-bash@gnu.org
Message-ID: <mailman.407.1444933790.7904.bug-bash@gnu.org>
References: <20151015173433.GS4446@vapier.lan>
Reply-To: chet.ramey@case.edu
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Trace: usenet.stanford.edu 1444933790 28829 208.118.235.17 (15 Oct 2015 18:29:50 GMT)
X-Complaints-To: action@cs.stanford.edu
Cc: chet.ramey@case.edu
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
X-Enigmail-Draft-Status: N1110
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
In-Reply-To: <20151015173433.GS4446@vapier.lan>
X-Junkmail-Status: score=10/60, host=mpv6.cwru.edu
X-Junkmail-Whitelist: YES (by domain whitelist at mpv2.tis.cwru.edu)
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic]
X-Received-From: 129.22.105.37
X-BeenThere: bug-bash@gnu.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/bug-bash>
List-Post: <mailto:bug-bash@gnu.org>
List-Help: <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
Xref: csiph.com gnu.bash.bug:11665

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