You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Actually in Windows, it converts all matches to lower-cases, which is unexpected, and would break if user-code then runs in POSIX. Should I open a separate bug for that?
@miracle2k is there a reason why not to use re.IGNORECASE in fnmatch() to implement chase-sensitiviness?
That would allow to avoid os.path.normcase() (but not slash replacement), and preserve the case of the captured matches.
Explanation why preserving the case of the matches is important
Assume a Makefile-like tool written in python (e.g. doit).
Scripts of such tools would rely on names formed out of glob-captured names, but these would be different depending on which OS the script has run. So the scripts are not be portable.
I believe that the behaviour of this library with regards to case should be the same as the regular Python one.
Returning the matched-parts of filenames is a functionality that is not present on python's 's glob and fnamtch modules, so maybe you can decide this independently.
Anyhow, I will provide a PR with a flag for this issue, because I'm really bitten by this one.
Thanks for your feedback.
I noticed that all tests fail on Windows - and the reason is that the matches are not preserved, and
that test-cases assume that os.sep char is always '/' .
Is my observation correct?
Oh, this is a bit misleading in the current implementation (0.7). Under Ubuntu:
Python 3.11.6 (main, Dec 28 2023, 19:53:52) [GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license"for more information.
>>> import glob2
>>> glob2.glob('*.jpg', case_sensitive=True)
['bar.JPG', 'foo.jpg']
Activity
ankostis commentedon Apr 20, 2017
It seems it does support both case in/sensitive matching, depending on the OS (see
glob2.fnmatch.fnmatchcase().The problem is that it is not configurable.
@miracle2k am I correct?
ankostis commentedon Apr 20, 2017
Actually in Windows, it converts all matches to lower-cases, which is unexpected, and would break if user-code then runs in POSIX. Should I open a separate bug for that?
ankostis commentedon Apr 20, 2017
@miracle2k is there a reason why not to use
re.IGNORECASEinfnmatch()to implement chase-sensitiviness?That would allow to avoid
os.path.normcase()(but not slash replacement), and preserve the case of the captured matches.Explanation why preserving the case of the matches is important
Assume a Makefile-like tool written in python (e.g. doit).
Scripts of such tools would rely on names formed out of glob-captured names, but these would be different depending on which OS the script has run. So the scripts are not be portable.
guettli commentedon Apr 20, 2017
@ankostis I don't know. My use case for this issue is gone. You can create a new and close this one if you want to.
miracle2k commentedon Apr 25, 2017
I believe that the behaviour of this library with regards to case should be the same as the regular Python one. By default this should remain so.
I am open to adding a flag for this.
You may also be able to implement this outside of the library via a custom globber subclass.
I am closing this since it's not actionable for me (I won't implement it myself), but a pull request is welcome.
ankostis commentedon Apr 25, 2017
Returning the matched-parts of filenames is a functionality that is not present on python's 's
globandfnamtchmodules, so maybe you can decide this independently.Anyhow, I will provide a PR with a flag for this issue, because I'm really bitten by this one.
Thanks for your feedback.
feat(miracle2k#10): configurable norm/case-sensitive/slashing to pres…
ankostis commentedon Apr 26, 2017
I noticed that all tests fail on Windows - and the reason is that the matches are not preserved, and
that test-cases assume that
os.sepchar is always'/'.Is my observation correct?
WIP feat(miracle2k#10): configurable norm/case-sensitive/slashing to …
feat(miracle2k#10): configurable norm/case-sensitive/slashes preservi…
miracle2k commentedon May 7, 2017
Re-opening to investigate behaviour change.
ankostis commentedon May 7, 2017
All tests was failing in Windows before the change.
There should not be any behavior change - if it happens, it's a mistake.
guettli commentedon Sep 23, 2019
What is the current state concerning "case in-sensitive globbing"?
ankostis commentedon Sep 23, 2019
Described in #19 (comment).
gergelyk commentedon Dec 29, 2023
Oh, this is a bit misleading in the current implementation (0.7). Under Ubuntu: