This means, for example, if one wants to match against the files 'foo1' and 'foo99', it is required to use a match of "*foo*", rather than just "foo*". Ie. you have to match against an arbitrary initial pathname, just to match a part of a filename. The test suite unfortunately misses this case.
The match option is worded to imply matching filenames, as opposed to directories. A user that wants to match specific directory trees can simply supply just those directories as arguments. And they can exclude subdirectories with the -x option. So to me, it makes sense to change the match option to match filenames as implied.
The fnmatch module does allow matching against strings such as "foo/bar*", ie. it allows path separators. So if possible, we could also say that matching against a directory would require using the path separator in the match string.
This means, for example, if one wants to match against the files 'foo1' and 'foo99', it is required to use a match of "*foo*", rather than just "foo*". Ie. you have to match against an arbitrary initial pathname, just to match a part of a filename. The test suite unfortunately misses this case.
The match option is worded to imply matching filenames, as opposed to directories. A user that wants to match specific directory trees can simply supply just those directories as arguments. And they can exclude subdirectories with the -x option. So to me, it makes sense to change the match option to match filenames as implied.
The fnmatch module does allow matching against strings such as "foo/bar*", ie. it allows path separators. So if possible, we could also say that matching against a directory would require using the path separator in the match string.