Created attachment 502746 [details, diff] PMS patch Bash 4.3 is stable everywhere, so we could update the Bash version in EAPI 7.
Does this version bring anything useful in? If not, then I think switching bash versions for the sake of it is only going to add more EAPI differences for no benefit.
Some potentially useful features added in BASH 4.3: The shell has `nameref' variables and new -n(/+n) options to declare and unset to use them, and a `test -R' option to test for them. The shell now allows assigning, referencing, and unsetting elements of indexed arrays using negative subscripts (a[-1]=2, echo ${a[-1]}) which count back from the last element of the array. The {x}<word redirection feature now allows words like {array[ind]} and can use variables with special meanings to the shell (e.g., BASH_XTRACEFD). The test/[/[[ `-v variable' binary operator now understands array references.
I don't think that list includes any "killer feature" but IMHO we shouldn't fall too much behind the current version. We could skip 4.3 of course and go for 4.4 (or later) in a future EAPI instead.
This has been rejected by the council in its 2017-11-12 meeting: https://projects.gentoo.org/council/meeting-logs/20171112-summary.txt Closing.
Reopening for bash-4.4 (or 5.0). IMHO, the following feature of bash-4.4 would be of particular interest. For example, it allows assigning the output of find -print0 to an array: d. The `mapfile' builtin now has a -d option to use an arbitrary character as the record delimiter, and a -t option to strip the delimiter as supplied with -d.
We may also want to require that the standard variables defined in chapter 7 must not be named references (declare -n), because this would cause issues for tests and presumably also for environment saving. https://projects.gentoo.org/pms/7/pms.html#x1-590007
Bash 5.0 is stable since a long time, so I believe that we should go for this version.
*** Bug 780009 has been marked as a duplicate of this bug. ***
As discussed in #gentoo-pms, depending on how quick progress is with implementation, we may now want to consider Bash 5.1 given it has recently been marked stable in Gentoo. There are no real new features relevant to us (other than perhaps negative array indices): >x. The shell now allows assigning, referencing, and unsetting elements of > indexed arrays using negative subscripts (a[-1]=2, echo ${a[-1]}) which > count back from the last element of the array. (Note that it contains stricter parsing of parameter expansion which caused a few ebuilds (see bug 762394) to stop working with 5.1, but they were in the wrong anyway.)
(In reply to Sam James from comment #9) > As discussed in #gentoo-pms, depending on how quick progress is with > implementation, we may now want to consider Bash 5.1 given it has recently > been marked stable in Gentoo. I have mixed feelings about this. With bash 5.1 requiring readline 8.1 which in turn broke a lot of stuff I'd rather remain on the safe side here. > > There are no real new features relevant to us (other than perhaps negative > array indices): > > >x. The shell now allows assigning, referencing, and unsetting elements of > > indexed arrays using negative subscripts (a[-1]=2, echo ${a[-1]}) which > > count back from the last element of the array. That one's from 4.3.
(In reply to Michał Górny from comment #10) > (In reply to Sam James from comment #9) > > As discussed in #gentoo-pms, depending on how quick progress is with > > implementation, we may now want to consider Bash 5.1 given it has recently > > been marked stable in Gentoo. > > I have mixed feelings about this. With bash 5.1 requiring readline 8.1 > which in turn broke a lot of stuff I'd rather remain on the safe side here. > I don't feel strongly about it here either way. > > > > There are no real new features relevant to us (other than perhaps negative > > array indices): > > > > >x. The shell now allows assigning, referencing, and unsetting elements of > > > indexed arrays using negative subscripts (a[-1]=2, echo ${a[-1]}) which > > > count back from the last element of the array. > > That one's from 4.3. Oh, ugh. I see now.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=fc728f5d4ab0dd58ef9cd940397a8990bb066d15 commit fc728f5d4ab0dd58ef9cd940397a8990bb066d15 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2021-05-12 12:26:32 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2021-05-24 04:36:45 +0000 Require bash-5.0 in EAPI 8 Bug: https://bugs.gentoo.org/636652 Signed-off-by: Michał Górny <mgorny@gentoo.org> Signed-off-by: Zac Medico <zmedico@gentoo.org> bin/eapi.sh | 6 +++++- bin/ebuild.sh | 2 ++ 2 files changed, 7 insertions(+), 1 deletion(-)
(In reply to Ulrich Müller from comment #6) > We may also want to require that the standard variables defined in chapter 7 > must not be named references (declare -n), because this would cause issues > for tests and presumably also for environment saving. > > https://projects.gentoo.org/pms/7/pms.html#x1-590007 Omitting this for now, unless I would get feedback that it leads to problems with the implementation otherwise.
Created attachment 711207 [details, diff] Ban nameref variables from exported and default scope (In reply to Ulrich Müller from comment #13) > > We may also want to require that the standard variables defined in chapter 7 > > must not be named references (declare -n), because this would cause issues > > for tests and presumably also for environment saving. > > > > https://projects.gentoo.org/pms/7/pms.html#x1-590007 > > Omitting this for now, unless I would get feedback that it leads to problems > with the implementation otherwise. So, nameref variables will break detection of bash arrays. For example, the default src_prepare() has this test: [[ $(declare -p PATCHES 2>/dev/null) == "declare -a"* ]] If PATCHES is a name reference and its target is an array, then declare -p will _not_ resolve the indirection, but output "declare -n" instead. We could work around this by updating the test to: ( unset "PATCHES[1]" 2>/dev/null ) using the fact that unset will return an error status when applied to an element (other than the zeroth) of a scalar variable, and executing it in a subshell so that the original array won't be affected. However, this looks like a very hackish solution which could break with future Bash versions. Therefore, ban nameref variables from exported and default scope.
> Created attachment 711207 [details, diff] [details, diff] > Ban nameref variables from exported and default scope Please review.
(In reply to Ulrich Müller from comment #14) As a matter of fact, bash-4.4 introduced a new @ operator in parameter expansion. So testing whether a variable is an array is now as simple as: [[ ${PATCHES@a} == *a* ]]
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pms.git/commit/?id=3f93cb5890b64d642a68aafa3997abe9dda46a10 commit 3f93cb5890b64d642a68aafa3997abe9dda46a10 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2021-05-25 15:59:13 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2021-06-05 08:55:34 +0000 Ban nameref variables from exported and default scope Bug: https://bugs.gentoo.org/636652 Signed-off-by: Ulrich Müller <ulm@gentoo.org> ebuild-format.tex | 2 ++ 1 file changed, 2 insertions(+) https://gitweb.gentoo.org/proj/pms.git/commit/?id=3b55b43b16c79e90af9cd99e9a71e469b988922a commit 3b55b43b16c79e90af9cd99e9a71e469b988922a Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2017-11-05 18:04:28 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2021-06-05 08:55:34 +0000 EAPI 8: Bash version is 5.0 Bug: https://bugs.gentoo.org/636652 Signed-off-by: Ulrich Müller <ulm@gentoo.org> eapi-differences.tex | 3 ++- ebuild-format.tex | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-)
