I see from one of the comments on my patch #103459 that there is a history to this issue (patch #103154) I had assumed that renaming modules and possibly breaking existing code was not an option, but this seems to have been considered in the discussion on that earlier patch. Is there any consensus on how to deal with this ? I would *really* like to get SOME fix -- either my patch, or a renaming of FCNTL, TERMIOS, SOCKET, into the next release. It's not clear to me whether the issues on other systems are the same. On mac-osx, the OS is BSD unix based and when using a unix file system, it's case sensitive. But the standard filesystem is Apple's HFS+, which is case preserving but case insensitive. ( That means that opening "abc" will succeed if there is a file named "abc", "ABC", "Abc" , "aBc" ... , but a directory listing will show "abc" ) I had guessed that the CHECK_IMPORT_CASE ifdefs and the corresponding configure switch were there for this sort of problem, and all I had to do was add a macosx implementation of check_case(), but returning false from check_case causes the search to fail -- it does not continue until it find a matching module. So it appears that I don't understand the issues on other platforms and what CHECK_IMPORT_CASE intends to fix. -- Steve Majewski
"SDM" == Steven D Majewski <sdm7g@virginia.edu> writes:
SDM> I see from one of the comments on my patch #103459 that there SDM> is a history to this issue (patch #103154) SDM> I had assumed that renaming modules and possibly breaking SDM> existing code was not an option, but this seems to have been SDM> considered in the discussion on that earlier patch. SDM> Is there any consensus on how to deal with this ? SDM> I would *really* like to get SOME fix -- either my patch, or a SDM> renaming of FCNTL, TERMIOS, SOCKET, into the next release. Our plan is to remove all of these modules and move the constants they define into the modules that provide the interface. Fred has already removed SOCKET, since all the constants are defined in socket. I don't think we'll get to the others in time for 2.1a2. SDM> It's not clear to me whether the issues on other systems are SDM> the same. On mac-osx, the OS is BSD unix based and when using SDM> a unix file system, it's case sensitive. But the standard SDM> filesystem is Apple's HFS+, which is case preserving but case SDM> insensitive. ( That means that opening "abc" will succeed if SDM> there is a file named "abc", "ABC", "Abc" , "aBc" ... , but a SDM> directory listing will show "abc" ) SDM> I had guessed that the CHECK_IMPORT_CASE ifdefs and the SDM> corresponding configure switch were there for this sort of SDM> problem, and all I had to do was add a macosx implementation of SDM> check_case(), but returning false from check_case causes the SDM> search to fail -- it does not continue until it find a matching SDM> module. Guido is strongly opposed to continuing after check_case returns false. His explanation is that imports ought to work whether all the there are multiple directories on sys.path or all the files are copied into a single directory. Obviously on file systems like HFS+, it would be impossible to have FCNTL.py and fcntl.py be in the same directory. Jeremy
On Fri, 2 Feb 2001, Jeremy Hylton wrote:
Our plan is to remove all of these modules and move the constants they define into the modules that provide the interface. Fred has already removed SOCKET, since all the constants are defined in socket. I don't think we'll get to the others in time for 2.1a2.
Guido is strongly opposed to continuing after check_case returns false. His explanation is that imports ought to work whether all the there are multiple directories on sys.path or all the files are copied into a single directory. Obviously on file systems like HFS+, it would be impossible to have FCNTL.py and fcntl.py be in the same directory.
This is in my previous message to the list, but since there seems to be (from my end, anyway) a long delay in list propagation, I'll repeat to you, Jeremy: The other problem is that without a patch, you can crash python with a mis-cased typo, as it tries to import the same module under two names:
import cStringIO import cstringio dyld: python2.0 multiple definitions of symbol _initcStringIO /usr/local/lib/python2.0/lib-dynload/cStringIO.so definition of _initcStringIO /usr/local/lib/python2.0/lib-dynload/cstringio.so definition of _initcStringIO
[ crash and burn back to shell prompt... ] instead of (with patch):
import cstringio Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named cstringio
A .py module doesn't crash like a .so module, but it still yields two (or more) different modules for each case spelling, which could be the source of some pretty hard to find bugs when MyModule.val != mymodule.val. ( Which is a more innocent mistake than the person who actually writes two different files for MyModule.py and mymodule.py ! ) ---| Steven D. Majewski (804-982-0831) <sdm7g@Virginia.EDU> |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- "All operating systems want to be unix, All programming languages want to be lisp."
Steve, I'm tasked with look at your patch for 2.1a2, and I have some questions and issues (since I'm just spinning up on this). First, what is the relationship of patch #103495 with the Cygwin patch #103154? They look like they address similar issues. Would you say that yours subsumes 103154, or at least will solve some of the problems jlt63 talks about in his patch? The other problem is that I do not have a Cygwin system to test on, and my wife isn't (yet :) psyched for me to do much debugging on her Mac (which doesn't have MacOSX on it yet). The best I can do is make sure your patch applies cleanly and doesn't break the Linux build. Would that work for you for 2.1a2? -Barry
"BAW" == Barry A Warsaw <barry@digicool.com> writes:
BAW> I'm tasked with look at your patch for 2.1a2, and I have some BAW> questions and issues (since I'm just spinning up on this). Steve, your patch is slightly broken for Linux (RH 6.1), which doesn't have a d_namelen slot in the struct dirent. I wormed around that by testing on #ifdef _DIRENT_HAVE_D_NAMLEN which appears to be the Linuxy way of determining the existance of this slot. If it's missing, I just strlen(dp->d_name). I'm doing a "make test" now and will test import of getpass to make sure it doesn't break on Linux. If it looks good, I'll upload a new version of the patch (which also contains consistent C style fixes) to SF and commit the patch for 2.1a2. -Barry
Patch passes regr test and import getpass on Linux, so I'm prepared to commit it for 2.1a2. Y'all are going to have to stress test it on other platforms. -Barry
On Fri, 2 Feb 2001, Barry A. Warsaw wrote:
Patch passes regr test and import getpass on Linux, so I'm prepared to commit it for 2.1a2. Y'all are going to have to stress test it on other platforms.
Revised patch builds on macosx. 'make test' finds the same 4 unrelated errors it always gets on macosx, so it's not any worse than before. It passes my own test cases for this problem. ---| Steven D. Majewski (804-982-0831) <sdm7g@Virginia.EDU> |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- "All operating systems want to be unix, All programming languages want to be lisp."
On Fri, Feb 02, 2001 at 02:05:40PM -0500, Barry A. Warsaw wrote:
Patch passes regr test and import getpass on Linux, so I'm prepared to commit it for 2.1a2. Y'all are going to have to stress test it on other platforms.
[Sorry for chiming in late, but my family just had its own beta release... :,)] I will test this on Cygwin ASAP and report back to the list. I really appreciate the inclusion of this patch in 2.1a2. Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Barry, On Fri, Feb 02, 2001 at 02:05:40PM -0500, Barry A. Warsaw wrote:
Patch passes regr test and import getpass on Linux, so I'm prepared to commit it for 2.1a2. Y'all are going to have to stress test it on other platforms.
This patch works properly under Cygwin too. The regression tests yield the same results as before and "import getpass" now behaves the same as on UNIX. Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
I don't have Cygwin either and what's more, I don't do much with MS-Windows, so I'm not familiar with some of the functions called in that patch. HFS+ filesystem on MacOSX is case preserving but case insensitive, which means that open("File") succeeds for any of: "file","File","FILE" ... The dirent functions verifies that there is in fact a "File" in that directory, and if not continues the search. There was some discussion about whether it should be #ifdef-ed diferently or more specifically. I don't know if any other system than macosx or Cygwin (if it works on that platform) require that test. (Although I'm glad you got it to compile on Linux, since the other likely case I can think of is LinuxPPC with a mac filesystem.) I guess if it compiles, then it doesn't hurt, except for the extra overhead. ( But, since it continues looking for a match, I couldn't use the CHECK_IMPORT_CASE switch. ) -- Steve On Fri, 2 Feb 2001, Barry A. Warsaw wrote:
First, what is the relationship of patch #103495 with the Cygwin patch #103154? They look like they address similar issues. Would you say that yours subsumes 103154, or at least will solve some of the problems jlt63 talks about in his patch?
The other problem is that I do not have a Cygwin system to test on, and my wife isn't (yet :) psyched for me to do much debugging on her Mac (which doesn't have MacOSX on it yet). The best I can do is make sure your patch applies cleanly and doesn't break the Linux build. Would that work for you for 2.1a2?
[Steven D. Majewski]
HFS+ filesystem on MacOSX is case preserving but case insensitive,
Same as Windows.
which means that open("File") succeeds for any of: "file","File","FILE" ...
Ditto.
The dirent functions verifies that there is in fact a "File" in that directory, and if not continues the search.
Which is what Jeremy said Guido is "strongly opposed to": His explanation is that imports ought to work whether all the there are multiple directories on sys.path or all the files are copied into a single directory. Obviously on file systems like HFS+, it would be impossible to have FCNTL.py and fcntl.py be in the same directory. In effect, you wrote your own check_case under a different name that-- unlike all other versions of check_case --ignores case mismatches. As I said before, I don't care for the current rules (and find_module has become such an #ifdef'ed minefield I'm not sure it's possible to tell what it does *anywhere* anymore), but there's no difference here between Windows filesystems and HFS+, so for the sake of basic sanity they must work the same way. So a retroactive -1 on this last-second patch -- and a waaaaay retroactive -1 on Python's behavior on Windows too.
"TP" == Tim Peters <tim.one@home.com> writes:
TP> So a retroactive -1 on this last-second patch -- and a waaaaay TP> retroactive -1 on Python's behavior on Windows too. So, let's tease out what the Right solution would be, and then see how close or if we can get there for 2.1. I've no clue what behavior Mac and Windows users would /like/ to see -- what would be most natural for them? OTOH, I like the Un*x behavior and I think I'd want to see platforms like Cygwin and MacOSX-on-non-HFS+ get as close to that as possible. Is it better to have uniform behavior across all platforms (modulo places like some Windows network fs's where that may not be possible)? Should Python's import semantics be identical across all platforms? OTOH, this is where the rubber meets the road so to speak, so some incompatibilities may be impossible to avoid. And what about Jython? -Barry
[Barry]
So, let's tease out what the Right solution would be, and then see how close or if we can get there for 2.1. I've no clue what behavior Mac and Windows users would /like/ to see -- what would be most natural for them? OTOH, I like the Un*x behavior and I think I'd want to see platforms like Cygwin and MacOSX-on-non-HFS+ get as close to that as possible.
Is it better to have uniform behavior across all platforms (modulo places like some Windows network fs's where that may not be possible)? Should Python's import semantics be identical across all platforms? OTOH, this is where the rubber meets the road so to speak, so some incompatibilities may be impossible to avoid.
And what about Jython?
Jython only does a File().exists() (which is similar to a stat()). So on WinNT, jython is behaving wrongly: Jython 2.0 on java1.3.0 (JIT: null) Type "copyright", "credits" or "license" for more information.
import stringio stringio.__file__ 'I:\\java\\Jython.CVS\\Lib\\stringio.py'
Yet I can't remember any bug reports where this have caused problems. regards, finn
finn wrote:
Jython only does a File().exists() (which is similar to a stat()). So on WinNT, jython is behaving wrongly:
Jython 2.0 on java1.3.0 (JIT: null) Type "copyright", "credits" or "license" for more information.
import stringio stringio.__file__ 'I:\\java\\Jython.CVS\\Lib\\stringio.py'
Yet I can't remember any bug reports where this have caused problems.
maybe that because it's easier for a Jython programmer to test his new library under CPython before releasing it to the world, than it is for a CPython programmer on Windows to test his library on a Unix box... yes-i've-been-bitten-by-this--ack-in-the-old-days-ly yrs /F
[Tim]
So a retroactive -1 on this last-second patch -- and a waaaaay retroactive -1 on Python's behavior on Windows too.
[Barry A. Warsaw]
So, let's tease out what the Right solution would be, and then see how close or if we can get there for 2.1. I've no clue what behavior Mac and Windows users would /like/ to see -- what would be most natural for them?
Nobody knows -- I don't think "they've" ever been asked. All *developers* want Unix semantics (keep going until finding an exact match -- that's what Steven's patch did). That's not good enough for Windows because of case-destroying network file systems and case-destroying old tools, but that + PYTHONCASEOK (stop on the first match of any kind) is good enough for Windows in my experience.
OTOH, I like the Un*x behavior
Of course you do -- you're a developer when you're not a bass player <wink>. No developer wants "file" to have 16 distinct potential meanings.
and I think I'd want to see platforms like Cygwin and MacOSX-on- non-HFS+ get as close to that as possible.
Well, MacOSX-on-non-HFS+ *is* Unix, right? So that should take care of itself (ya, right). I don't understand what Cygwin does; here from a Cygwin bash shell session: tim@fluffy ~ $ touch abc tim@fluffy ~ $ touch ABC tim@fluffy ~ $ ls abc tim@fluffy ~ $ wc AbC 0 0 0 AbC tim@fluffy ~ $ ls A* ls: A*: No such file or directory tim@fluffy ~ So best I can tell, they're like Steven: working with a case-insensitive filesystem but trying to make Python insist that it's not, and what basic tools there do about case is seemingly random (wc doesn't care, shell expansion does, touch doesn't, rm doesn't (not shown) -- maybe it's just shell expansion that's trying to pretend this is Unix? oh ya, shell expansion and Python import -- *that's* a natural pair <wink>).
Is it better to have uniform behavior across all platforms (modulo places like some Windows network fs's where that may not be possible)?
I think so, but I've already said that. "import" is a language statement, not a platform file operation at heart. Of *course* people expect open("FiLe") to open files "file" or "FILE" (or even "FiLe" <wink>) on Windows, but inside Python stmts they expect case to matter.
Should Python's import semantics be identical across all platforms? OTOH, this is where the rubber meets the road so to speak, so some incompatibilities may be impossible to avoid.
I would prefer it, but if Guido thinks Python's import semantics should derive from the platform's filesystem semantics, fine, and then any "Python import should pretend it's Unix" patch should get tossed without further debate. But Guido doesn't think that either, else Windows Python wouldn't complain about "import FILE" finding file.py first (there is no other tool on Windows that cares at all -- everything else would just open file.py). So I view the current rules as inexplicable: they're neither platform-independent nor consistent with the platform's natural behavior (unless that platform has case-sensitive filesystem semantics). Bottom line: for the purpose of import-from-file (and except for case-destroying filesystems, where PYTHONCASEOK is the only hope), we *can* make case-insensitive case-preserving filesystems "act like" they were case-sensitive with modest effort. We can't do the reverse. That would lead to explainable rules and maximal portability. I'll worry about moving all my Python files into a single directory when it comes up (hasn't yet).
And what about Jython?
Oh yeah? What about Vyper <wink>? otoh-if-i-actually-cared-about-case-i-would-never-have-adopted- this-silly-sig-style-ly y'rs - tim
On Sun, Feb 04, 2001 at 03:13:29AM -0500, Tim Peters wrote:
[Barry A. Warsaw]
So, let's tease out what the Right solution would be, and then see how close or if we can get there for 2.1. I've no clue what behavior Mac and Windows users would /like/ to see -- what would be most natural for them?
On 2001-Jan-11 07:56, Jason Tishler wrote:
I have created a (hacky) patch, that solves this problem for both Cygwin and Win32. I can redo it so that it only affects Cygwin and leaves the Win32 functionality alone. I would like to upload it for discussion...
Part of my motivation when submitting patch 103154, was to attempt to elicit the "right" solution.
I don't understand what Cygwin does; here from a Cygwin bash shell session:
...
So best I can tell, they're like Steven: working with a case-insensitive filesystem but trying to make Python insist that it's not, and what basic tools there do about case is seemingly random (wc doesn't care, shell expansion does, touch doesn't, rm doesn't (not shown) -- maybe it's just shell expansion that's trying to pretend this is Unix?
Sorry, but I don't agree with your assessment that Cygwin's treatment of case is "seemingly random." IMO, Cygwin behaves appropriately regarding case for a case-insensitive, but case-preserving file system. The only "inconsistency" that you found is just one of bash's idiosyncrasies -- how it handles glob-ing. Note that one can use "shopt -s nocaseglob" to get case-insensitive glob-ing with bash on Cygwin *and* UNIX.
So I view the current rules as inexplicable: they're neither platform-independent nor consistent with the platform's natural behavior (unless that platform has case-sensitive filesystem semantics).
Agreed.
Bottom line: for the purpose of import-from-file (and except for case-destroying filesystems, where PYTHONCASEOK is the only hope), we *can* make case-insensitive case-preserving filesystems "act like" they were case-sensitive with modest effort.
I feel that the above behavior would be best for Cygwin Python. I hope that Steven's patch (i.e., 103495) or a modified version of it remains as part of Python CVS.
We can't do the reverse. That would lead to explainable rules and maximal portability.
Sorry but I don't grok the above. Tim, can you try again? BTW, importing of builtin modules is case-sensitive even on platforms such as Windows. Wouldn't it be more consistent if all imports regardless of type were case-sensitive? Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
Jason wrote:
BTW, importing of builtin modules is case-sensitive even on platforms such as Windows. Wouldn't it be more consistent if all imports regardless of type were case-sensitive?
umm. what kind of imports are not case-sensitive today?
import strOP # builtin Traceback (innermost last): File "<stdin>", line 1, in ? ImportError: No module named strOP
import stringIO # python Traceback (innermost last): File "<stdin>", line 1, in ? NameError: Case mismatch for module name stringIO (filename C:\py152\lib\StringIO.py)
import _Tkinter # binary extension Traceback (innermost last): File "<stdin>", line 1, in ? NameError: Case mismatch for module name _Tkinter (filename C:\py152\_tkinter.pyd)
Cheers /F
[Fredrik Lundh]
umm. what kind of imports are not case-sensitive today?
fredrik.py and Fredrik.py, both on the path. On Windows it does or doesn't blow up, depending on which one you import and which one is found first on the path. On Unix it always works. Imports on Windows aren't so much case-sensitive as casenannying <wink>.
On Mon, 5 Feb 2001, Tim Peters wrote:
[Fredrik Lundh]
umm. what kind of imports are not case-sensitive today?
fredrik.py and Fredrik.py, both on the path. On Windows it does or doesn't blow up, depending on which one you import and which one is found first on the path. On Unix it always works.
On Unix it always works ... depending on the filesystem. ;-)
Imports on Windows aren't so much case-sensitive as casenannying <wink>.
[Jason Tishler]
Sorry, but I don't agree with your assessment that Cygwin's treatment of case is "seemingly random." IMO, Cygwin behaves appropriately regarding case for a case-insensitive, but case-preserving file system.
Sorry, you can't disagree with that <wink>: i.e., you can disagree that Cygwin *is* inconsistent, but you can't tell me it didn't *appear* inconsistent to me the first time I played with it. The latter is just a fact. It doesn't mean it *is* inconsistent. First impressions are what they are. The heart of the question for Python is related, though: you say Cygwin behaves appropriately. Fine. If I "cat FiLe", it will cat a file named "file" or "FILE" or "filE" etc. But at the same time, you want Python to *ignore* "filE.py" when Python does "import FiLe". The behavior you want from Python is then inconsistent with what Cygwin does elsewhere. So if Cygwin's behavior is "appropriate" for the filesystem, then what you want Python to do must be "inappropriate" for the filesystem. That's what I want too, but it *is* inappropriate for the filesystem, and I want to be clear about that. Basic sanity requires that Python do the same thing on *all* case-insensitive case-preserving filesystems, to the fullest extent possible. Python's DOS/Windows behavior has priority by a decade. I'm deadly opposed to making a special wart for Cygwin (or the Mac), but am in favor of changing it on Windows too.
We can't do the reverse. That would lead to explainable rules and maximal portability.
Sorry but I don't grok the above. Tim, can you try again?
"That" referred to the sentence before the first one you quoted, although it takes psychic powers to intuit that. That is, in the interest of maximal portability, explainability and predictability, import can make case-insensitive filesystems act as if they were case-sensitive, but it's much harder ("we can't") to make C-S systems act C-I.
[Sorry for letting this thread hang, but I'm back from paternity leave so I will be more responsive now. Well, at least between normal business hours that is.] On Mon, Feb 05, 2001 at 04:01:49PM -0500, Tim Peters wrote:
Basic sanity requires that Python do the same thing on *all* case-insensitive case-preserving filesystems, to the fullest extent possible. Python's DOS/Windows behavior has priority by a decade. I'm deadly opposed to making a special wart for Cygwin (or the Mac), but am in favor of changing it on Windows too.
May be if we can agree on how import should behave, then we will have a better chance of determining the best way to implement it sans warts? So, along these lines I propose that import from a file behave the same on both case-sensitive and case-insensitive/case-preserving filesystems. This will help to maximize portability between platforms like UNIX, Windows, and Mac. Unfortunately, something like the PYTHONCASEOK caveat still needs to be preserved for case-destroying filesystems. Any feedback is appreciated -- I'm just trying to help get closure on this issue by Beta 1. Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
[Sorry for letting this thread hang, but I'm back from paternity leave so I will be more responsive now. Well, at least between normal business hours that is.]
On Mon, Feb 05, 2001 at 04:01:49PM -0500, Tim Peters wrote:
Basic sanity requires that Python do the same thing on *all* case-insensitive case-preserving filesystems, to the fullest extent possible. Python's DOS/Windows behavior has priority by a decade. I'm deadly opposed to making a special wart for Cygwin (or the Mac), but am in favor of changing it on Windows too.
May be if we can agree on how import should behave, then we will have a better chance of determining the best way to implement it sans warts? So, along these lines I propose that import from a file behave the same on both case-sensitive and case-insensitive/case-preserving filesystems. This will help to maximize portability between platforms like UNIX, Windows, and Mac. Unfortunately, something like the PYTHONCASEOK caveat still needs to be preserved for case-destroying filesystems.
Any feedback is appreciated -- I'm just trying to help get closure on this issue by Beta 1.
Tim has convinced me that the proper rules are simple: - If PYTHONCASEOK is set, use the first file found with a case-insensitive match. - If PYTHONCASEOK is not set, and the file system is case-preserving, ignore (rather than bail out at) files that don't have the proper case. Tim is in charge of cleaning up the code, but he'll need help for the Cygwin and MacOSX parts. --Guido van Rossum (home page: http://www.python.org/~guido/)
Tim, On Mon, Feb 12, 2001 at 05:23:21PM -0500, Guido van Rossum wrote:
Tim is in charge of cleaning up the code, but he'll need help for the Cygwin and MacOSX parts.
I'm willing to help develop, test, etc. the Cygwin stuff. Just let me know how I can assist you. Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
[Jason Tishler]
I'm willing to help develop, test, etc. the Cygwin stuff. Just let me know how I can assist you.
Jason, doesn't the current CVS Python already do what you want? I thought that was the case, due to the HAVE_DIRENT_H #ifdef'ery Steven introduced. If not, scream at me. My intent is to get rid of the HAVE_DIRENT_H #ifdef *test*, but not the code therein, and add new versions of MatchFilename that work for systems (like regular old Windows) that don't support opendir() natively. I didn't think Cygwin needed that -- scream if that's wrong. However, even if you are happy with that (& I won't hurt it), sooner or later you're going to try accessing a case-destroying network filesystem from Cygwin, so I believe you need more code to honor PYTHONCASEOK too (it's the only chance anyone has in the face of a case-destroying system). Luckily, with a new child in the house, you have plenty of time to think about this, since you won't be sleeping again for about 3 years anyway <wink>.
Tim, On Tue, Feb 13, 2001 at 12:34:23AM -0500, Tim Peters wrote:
[Jason Tishler]
I'm willing to help develop, test, etc. the Cygwin stuff. Just let me know how I can assist you.
Guido said that you needed help with Cygwin and MacOSX, so I was just offering my help. I know that you have the "development" in good shape so let me know if I can help with testing Cygwin or other platforms.
Jason, doesn't the current CVS Python already do what you want?
Yes.
I thought that was the case, due to the HAVE_DIRENT_H #ifdef'ery Steven introduced. If not, scream at me. My intent is to get rid of the HAVE_DIRENT_H #ifdef *test*, but not the code therein, and add new versions of MatchFilename that work for systems (like regular old Windows) that don't support opendir() natively. I didn't think Cygwin needed that -- scream if that's wrong.
You are correct -- Cygwin supports opendir() et al.
However, even if you are happy with that (& I won't hurt it),
I am (and thanks).
sooner or later you're going to try accessing a case-destroying network filesystem from Cygwin, so I believe you need more code to honor PYTHONCASEOK too (it's the only chance anyone has in the face of a case-destroying system).
Is it possible to make the PYTHONCASEOK caveat orthogonal to the platform so it can be enabled to combat case-destroying filesystems for any platform?
Luckily, with a new child in the house, you have plenty of time to think about this, since you won't be sleeping again for about 3 years anyway <wink>.
Agreed -- this is not our first so we "know." I *have* been thinking about this issue and others 24 hours a day for the last two weeks. I'm just finding it difficult to actually *do* anything with one hand and no sleep... :,) Thanks, Jason -- Jason Tishler Director, Software Engineering Phone: +1 (732) 264-8770 x235 Dot Hill Systems Corp. Fax: +1 (732) 264-8798 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com Hazlet, NJ 07730 USA WWW: http://www.dothill.com
On Mon, 12 Feb 2001, Guido van Rossum wrote:
Tim has convinced me that the proper rules are simple:
- If PYTHONCASEOK is set, use the first file found with a case-insensitive match.
- If PYTHONCASEOK is not set, and the file system is case-preserving, ignore (rather than bail out at) files that don't have the proper case.
Tim is in charge of cleaning up the code, but he'll need help for the Cygwin and MacOSX parts.
Thanks Tim (for convincing Guido). Now I don't have to post (and you don't have to read!) my 2K word essay on why Guido's old rules were inconsistent and might have caused TEOTWAWKI if fed into the master computer. Just let me know if you need me to test anything on macosx. -- Steve M.
On Sun, 4 Feb 2001, Tim Peters wrote:
Well, MacOSX-on-non-HFS+ *is* Unix, right? So that should take care of itself (ya, right). I don't understand what Cygwin does; here from a Cygwin bash shell session:
tim@fluffy ~ $ touch abc
tim@fluffy ~ $ touch ABC
tim@fluffy ~ $ ls abc
tim@fluffy ~ $ wc AbC 0 0 0 AbC
tim@fluffy ~ $ ls A* ls: A*: No such file or directory
tim@fluffy ~
So best I can tell, they're like Steven: working with a case-insensitive filesystem but trying to make Python insist that it's not, and what basic tools there do about case is seemingly random (wc doesn't care, shell expansion does, touch doesn't, rm doesn't (not shown) -- maybe it's just shell expansion that's trying to pretend this is Unix? oh ya, shell expansion and Python import -- *that's* a natural pair <wink>).
Just for the record, I get exactly the same results on macosx as you did on Cygwin. The logic behind the seemingly random results is, I'm sure, the same logic behind my patch: accessing the file itself is case insensitive; but the directory entry (accessed by shell globbing) is case preserving. -- Steve Majewski
participants (9)
-
barry＠digicool.com -
bckfnn＠worldonline.dk -
Fredrik Lundh -
Fredrik Lundh -
Guido van Rossum -
Jason Tishler -
Jeremy Hylton -
Steven D. Majewski -
Tim Peters