[Steven D. Majewski]
... 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.
I don't care about LinuxPPC right now. When someone steps up to champion that platform, they can deal with it then. What I am interested in is supporting the platforms we *do* have warm bodies looking at, and not regressing on any of them. I'm surprised nobody on Linux already screamed.
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.
I expect it's enabled everywhere the #ifdef's in the patch enabled it <wink/frown>. But I don't care about the past either, I want to straighten it out *now*.
( 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. )
Then this is the right time. Play along by pretending that OSX is the special case that it is <0.9 wink>.
... 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.
check_case will be used differently now.
... 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! )
Please just solve the problem for the platforms you're actually running on -- case-insensitive filesystems are not "Unix only" in any meaningful sense of that phrase, and each not-really-Unix platform is likely to have its own stupid gimmicks for worming around this problem anyway. For example, Cygwin defers to the Windows API. Great! That solves the problem there. Generalization is premature.
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. )
Good! I'm not going to wait for that, though. I desperately need a nap, but when I get up I'll check in changes that should be sufficient for the Windows and Cygwin parts of this, without regressing on other platforms. We'll then have to figure out whatever #ifdef'ery is needed for your platform(s).
getenv() works on OSX (it's the BSD unix implementation).
So it's *kind* of like Unix after all <wink>.
( I *think* that Jack has the MacPython get the variables from Pythoprefs file settings. )
Haven't heard from him, but getenv() is used freely in the Python codebase elsewhere, so I figure he's got *some* way to fake it. So I'm not worried about that anymore (until Jack screams about it).