fnmatch does not follow Unix fnmatch functionality

[varunagrawal]

BPO	31123
Nosy	@bitdancer

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2017-08-04.23:22:19.542>
labels = ['3.7', 'type-feature', 'library']
title = 'fnmatch does not follow Unix fnmatch functionality'
updated_at = <Date 2017-08-08.13:14:33.618>
user = 'https://bugs.python.org/VarunAgrawal'

bugs.python.org fields:

activity = <Date 2017-08-08.13:14:33.618>
actor = 'r.david.murray'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2017-08-04.23:22:19.542>
creator = 'Varun Agrawal'
dependencies = []
files = []
hgrepos = []
issue_num = 31123
keywords = []
message_count = 5.0
messages = ['299763', '299764', '299767', '299874', '299917']
nosy_count = 2.0
nosy_names = ['r.david.murray', 'Varun Agrawal']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue31123'
versions = ['Python 3.7']

[varunagrawal]

Currently, the fnmatch module in Python does not operate like the Unix equivalent command. This is especially the case with patterns such as dir/ which does not match directory path returned by os (which would be dir) and neither does the pattern match the underlying files and sub-directories. Adding these functionalities so that fnmatch matches it's Unix equivalent would make it much more powerful to use.

Glob is not useful since glob is a special case that matches only with the current directory paths rather than the a general purpose filename pattern matcher.

[bitdancer]

I don't believe there is an equivalent unix command. Are you referring to the fnmatch glibc function? Can you demonstrate the differences? I doubt we will change the functionality, but that would be the minimum starting point for a discussion.

[bitdancer]

Looking at the fnmatch man page, it looks like there are option flags that some shells use that our fnmatch doesn't support. I'm not sure if supporting them is a good idea for us or not, but it is probably worth discussing. I suspect our fnmatch was implemented before gnu added those extensions.

[varunagrawal]

Hi David,
It seems you already took a look at the man page. There are some subtle differences such as being unable to match to a directory when the pattern ends with a forward slash.
Overall, I'd like to see fnmatch be used to create a program that can perform pattern matching of files similar to how a gitignore works. Currently, this involves quite a bit of hackery to get working well.

[bitdancer]

That seems like a reasonable use case, but is fnmatch what git is using for this? If so, what is the feature set required? In any case, the existing functionality must remain as is for backward compatibility reasons, so this would either be a new function or keyword controlled optional behavior.

(You will note that our fnmatch documentation specifically mentions treating / as a normal character.)

[hauntsaninja]

Note that the filename separator ('/' on Unix) is not special to this module.

Yup, as bitdancer mentions, this behaviour is documented, and has been documented for as long as fnmatch has been documented — since 1997 e76b7a8fcd7

Maybe your needs would be better met by something like https://github.com/cpburnz/python-pathspec