gward at cnri
Feb 17, 2000, 7:48 AM
Post #1 of 3
(103 views)
Permalink
|
Hi all --
I have recently been playing with the fnmatch module, and learned that *
and ? as considered by 'fnmatch.translate()' match *all* characters,
including slashes, colons, backslashes -- in short, whatever happens to
be "special" characters for pathnames on the current platform.
In other words, "foo?bar.py" matches both "foo_bar.py" and "foo/bar.py".
This is not the way any Unix shells that I know of work, nor is it how
the wildcard-expanding MS-DOS system calls that I dimly remember from a
decade or so back worked. I dunno how wildcard expansion is done under
Windows nowadays, but I wouldn't expect * and ? to match colons or
backslashes there any more than I expect them to match slash under a
Unix shell.
So is this a bug or a feature?
Seems to me that a good fix would be to extend 'fnmatch.translate()' to
have some (maybe all?) of the flags that the standard Unix library
'fnmatch()' supports. The flag in question here is FNM_PATHNAME, which
is described in the Solaris manual as
FNM_PATHNAME If set, a slash (/) character
in string will be explicitly
matched by a slash in pattern;
it will not be matched by
either the asterisk (*) or
question-mark (?) special
characters, nor by a bracket
([]) expression.
If not set, the slash charac-
ter is treated as an ordinary
character.
and in the GNU/Linux manual as
FNM_PATHNAME
If this flag is set, match a slash in string only
with a slash in pattern and not, for example, with
a [] - sequence containing a slash.
To adapt this to Python's 'fnmatch.translate()', I think "slash" would
have to be generalized to "special character", which is platform
dependent:
Unix /
DOS/Windows : \ (and maybe / too?)
Mac :
I propose changing the signature of 'fnmatch.translate()' from
def translate(pat)
to at least
def translate(pat,pathname=0)
and possibly to
def translate(pat,
pathname=0,
noescape=0,
period=0,
leading_dir=0,
casefold=0)
which follows the lead of GNU 'fnmatch()'. (Solaris 'fnmatch()' only
supports the PATHNAME, NOESCAPE, and PERIOD flags; the GNU man page says
LEADING_DIR and CASEFOLD are GNU extensions. I like GNU extensions.)
Similar optional parameters would be added to 'fnmatch()' and
'fnmatchcase()', possibly dropping the 'casefold' argument since it's
covered by which function you're calling.
I have yet to fully grok the meaning of those other four flags, though,
so I'm not sure how easy it would be to hack them into
'fnmatch.translate()'.
Opinions?
Greg
|
