glob.translate incorrectly matches path separator in character ranges

[euangoodbrand]

Bug report

Bug description:

Description

The glob.translate function in Python 3.13 doesn't properly handle path separators when they're included in character ranges. According to the documentation, "wildcards do not match path separators," but this isn't enforced for character ranges that include the path separator.

Expected behavior

Character ranges in glob patterns should not match path separators, consistent with the behavior of single character wildcards (?) and the documented behavior of the module.

Actual behavior

Character ranges that include the path separator (e.g., [%-0] which includes the / character) will match the path separator, contradicting the documented behavior.

Code to reproduce

import glob
import re

# Proper behavior with ? wildcard
r1 = re.compile(glob.translate('a?c', seps=['/']))
print(r1)  # (?s:a[^/]c)\Z
print(r1.match('abc'))  # match object
print(r1.match('a/c'))  # None, correctly doesn't match path separator

# Incorrect behavior with character range
r2 = re.compile(glob.translate('a[%-0]c', seps=['/']))
print(r2)  # (?s:a[%-0]c)\Z
print(r2.match('a0c'))  # match object
print(r2.match('a/c'))  # match object, incorrectly matches path separator

### CPython versions tested on:

3.13

### Operating systems tested on:

_No response_

---

Linked PRs

• gh-130942: Fix path seperator matched in character ranges for glob.translate #130989

[dkaszews]

Hi, I am the author of the original find, so let me add a bit of context and rationale.

The reason I consider this a bug in glob.translate is that it does not match the behavior of bash, nor of glob.glob which correctly ignore the path separator inside a character class, even if a single character and not a part of range:

$ mkdir a
$ touch a/c
$ shopt -s failglob
$ ls -1 a/c
a/c
$ ls -1 a[/]c
-bash: no match: a[/]c
$ ls -1 a[%-0]c
-bash: no match: a[%-0]c
$ python -c 'import glob; print(glob.glob("a/c"))' 
[ 'a/c' ]
$ python -c 'import glob; print(glob.glob("a[/]c"))'
[]
$ python -c 'import glob; print(glob.glob("a[%-0]c"))'
[]

From man fnmatch(3):

FNM_PATHNAME
              If this flag is set, match a slash in string only with a
              slash in pattern and not by an asterisk (*) or a question
              mark (?) metacharacter, nor by a bracket expression ([])
              containing a slash.

[dmitya26]

Hello. I can make a PR for this issue.

[picnixz]

The relevant manpage paragraph for this issue is (emphasis mine)

Globbing is applied on each of the components of a pathname separately.
A '/' in a pathname cannot be matched by a '?' or '*' wildcard, or by a range
like "[.-0]". A range containing an
explicit '/' character is syntactically incorrect. (POSIX requires that
syntactically incorrect patterns are left unchanged.)

As for the second issue, please open a separate ticket.

I think the issue stems from the fact that glob.translate is based on fnmatch.translate for which separators have no special meaning. However I am on mobile and it's hard to debug this.

cc @barneygale

[picnixz]

Now, before opening a PR, I want to be sure that the pattern translated by glob and the pattern used by glob.glob are equivalent in the sense that:

glob.glob(p) == [
  s in all_paths
  if re.match(glob.translate(p), s)
]

namely regex + glob.translate is the slow alternative of glob.glob.

[dkaszews]

@picnixz Thank you for pulling up that manpage, globbing is documented in several of them, that one is in fact most explicitly relevant here.

As for the second issue, please open a separate ticket

Created #130985

pattern translated by glob and the pattern used by glob.glob

That would be my expectation as well. In fact, I found this issue by trying to use Python's glob.translate to generate test cases for my C++ code which does exactly that - implement globbing via regex translation.

[picnixz]

Sorry for having misread the second issue and make you open a separate issue but I don't think there is an issue with [][!] (let's comtinue the discussion in the other issue)

[dmitya26]

Once I verify that glob.glob(p) and re.match(glob.translate(s), p) have the same output given the issue's testcase, would it be okay for me to proceed with the PR?

[picnixz]

Probably, but I also want @barneygale's input on this beforehand as I think he's the one who added glob.translate() in 3.13 (but I may be wrong). I may be wrong in my assumptions as I don't remember exactly the specs here (though my gut feeling is telling me that there's an issue as we don't align with the glob manpage).

[barneygale]

This is a legitimate bug in glob.translate() - it shouldn't be possible to match a path separator with a wildcard (including a [group]). Thanks for reporting - happy to review a fix.

[picnixz]

@dmitya26 go ahead with a PR :')

[dmitya26]

I will, I'm adding the unit test for it and will open one after I finish with that in a few minutes.

[picnixz]

No rush needed! I just wanted to confirm that your PR will be welcome!