Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #11665

Re: updating shopt compat settings to include current version

From Chet Ramey <chet.ramey@case.edu>
Newsgroups gnu.bash.bug
Subject Re: updating shopt compat settings to include current version
Date 2015-10-15 14:28 -0400
Message-ID <mailman.407.1444933790.7904.bug-bash@gnu.org> (permalink)
References <20151015173433.GS4446@vapier.lan>

Show all headers | View raw


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

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: updating shopt compat settings to include current version Chet Ramey <chet.ramey@case.edu> - 2015-10-15 14:28 -0400

csiph-web