Re^3: -e " " returns true

To complete the picture, I finally tracked down the mysterious PerlDir_map(A|W) to win32\vdir.h. This appears to be a C++ Dir object class stolen from somewhere.

The MapPath(A|W) methods are very strange indeed. They eventually call GetFullPathName(A|W) to convert relative paths to absolute paths, but go through a heap of pre-conditioning of the input path before doing so. This pre-conditioning appears to be intended to work around bugs in that API that existed back then.

However, GetFullPathName still exibits some very peculiar bugs, including rendering various non-pathnames as the cwd as described earlier.

This problem is an accumulation of OS bugs, a couple of perl implementation fopars, and too many layers. It's gonna be a bitch to fix.

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon

Comment on Re^3: -e " " returns true

Replies are listed 'Best First'.
Re^4: -e " " returns true by DrHyde (Prior) on Jul 07, 2004 at 16:14 UTC
So let's hope there's a p5p person reading this!	[reply]
Re^5: -e " " returns true by BrowserUk (Patriarch) on Jul 07, 2004 at 16:31 UTC
I doubt it would help much. Fixes require motivation and from what I saw of my attempts to follow the p5p processes, this Win32 bug is unlikely to affect many of the p5p people. If the OP perlbug'd it, it might get picked up by someone at ActiveState. Examine what is said, not who speaks. "Efficiency is intelligent laziness." -David Dunham "Think for yourself!" - Abigail "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon	[reply] [d/l]