On Tue, 27 Feb 2001, Tim Peters wrote:
I don't like the new MatchFilename, because it triggers on *all* platforms that #define HAVE_DIRENT_H.
I mentioned this when I originally submitted the patch. The intent was that it be *able* to compile on any unix-like platform -- in particular, I was thinking LinuxPPC was the other case I could think of where someone might want to use a HFS+ filesystem - but that Darwin/MacOSX was likely to be the only system in which that was the default.
Anyone, doesn't that trigger on straight Linux systems too (all I know is that it's part of the Single UNIX Specification)?
Yes. Barry added the _DIRENT_HAVE_D_NAMELINE to handle a difference in the linux dirent structs. ( I'm not sure if he caught my initial statement of intent either, but then the discussion veered into whether the patch should have been accepted at all, and then into the discussion of a general solution... ) I'm not happy with the ineffeciency either, but, as I noted, I didn't expect that it would be enabled by default elsewhere when I submitted it. ( And my goal for OSX was just to have a version that builds and doesn't crash much, so searching for a more effecient solution was going to be the next project. )
Would rather dump MatchFilename and rewrite in terms of the old check_case (which should run much quicker, and already comes in several appropriate platform-aware versions -- and I clearly minimize the chance of breakage if I stick to that time-tested code).
The reason I started from scratch, you might recall, was that before I understood that the Windows semantics was intended to be different, I tried adding a Mac version of check_case, and it didn't do what I wanted. But that wasn't a problem with any of the existing check_case functions, but was due to how check_case was used.
Steven, there is a "#ifdef macintosh" version of check_case already. Will that or won't that work correctly on your variant of Mac? If not, would you please supply a version that does (along with the #ifdef'ery needed to recognize your Mac variant)?
One problem is that I'm aiming for a version that would work on both the open source Darwin distribution ( which is mach + BSD + some Apple extensions: Objective-C, CoreFoundation, Frameworks, ... but not most of the macosx Carbon and Cocoa libraries. ) and the full MacOSX. Thus the reason for a unix only implementation -- the info may be more easily available via MacOS FSSpec's but that's not available on vanilla Darwin. ( And I can't, for the life of me, thing of an effecient unix implementation -- UNIX file system API's + HFS+ filesystem semantics may be an unfortunate mixture! ) In other words: I can rename the current version to check_case and fix the args to match. (Although, I recall that the args to check_case were rather more awkward to handle, but I'll have to look again. ) It also probably shouldn't be "#ifdef macintosh" either, but that's a thread in itself!
Steven and Jack, does getenv() work on both your flavors of Mac? I want to make PYTHONCASEOK work for you too.
getenv() works on OSX (it's the BSD unix implementation). ( I *think* that Jack has the MacPython get the variables from Pythoprefs file settings. ) -- Steve Majewski