Bug 907061

Summary:	app-shells/bash: new globskipdots shopt in 5.2 raises minor backward-compatibility concerns
Product:	Gentoo Linux	Reporter:	kfm
Component:	Current packages	Assignee:	Gentoo's Team for Core System packages <base-system>
Status:	CONFIRMED ---
Severity:	normal	CC:	dev-portage
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
URL:	https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13_03
Whiteboard:
Package list:		Runtime testing required:	---
Bug Depends on:
Bug Blocks:	881379

Description kfm 2023-05-24 07:35:04 UTC

The release notes for 5.2 state the following:-

"The new `globskipdots' shell option forces pathname expansion never to return `.' or `..' unless explicitly matched. It is enabled by default."

This is a backwards-incompatible change, because the option in question defaults to being enabled. Further, it violates the standard rules for matching against pathnames containing a leading period.

$ declare -p BASH_VERSION
declare -- BASH_VERSION="5.1.16(1)-release"
$ cd /var/empty; printf %s\\n .?
..

$ declare -p BASH_VERSION
declare -- BASH_VERSION="5.2.15(1)-release"
$ cd /var/empty; printf %s\\n .?
.?

Is it covered by BASH_COMPAT? Of course not!

$ BASH_COMPAT=50
$ printf %s\\n .?
.?

That being said, I consider it to be exceedingly unlikely that this change meaningfully impacts upon portage or any of the ebuilds and eclasses that exist, both of the official and unofficial variety. Nevertheless, I decided to report this because, from the standpoint of PMS purporting to retain backward-compatibility, portage's present behaviour is not strictly correct.

Comment 1 Sam James archtester

2023-05-25 03:39:04 UTC

I'll tentatively block bug 881379 just as it's something we should review before proceeding with stabilisation, even if we don't keep it as a blocker.