Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re^2: -e " " returns true

by DrHyde (Prior)
on Jul 06, 2004 at 08:23 UTC ( [id://372039]=note: print w/replies, xml ) Need Help??


in reply to Re: -e " " returns true
in thread -e " " returns true

I found a 1996 article in "Microsoft Systems Journal" which indicates that Win32 does some very odd things with filenames with spaces in them.

Replies are listed 'Best First'.
Re^3: -e " " returns true
by BrowserUk (Patriarch) on Jul 06, 2004 at 12:54 UTC

    On this occasion, it appears that the problem is internal to Perl--with caveats.

    The problem occurs in these two lines from win32\win32.c (line numbers are approximate (5.8.4) because I've added debug code):

    1222: pwbuffer = PerlDir_mapW(wbuffer); ... 1228: path = PerlDir_mapA(path);

    Prior to these to lines the vars; path / wbuffer contain the bad paths being tested ( ' ', ' . . ' etc. ), but after they contain the fully expanded current working directory. They should not.

    So, the problem is in the routines PerlDir_mapW() / PerlDir_mapA(). The stat being returned for non-existant directory paths is that of the current working directory.

    But there, my trail grows cold. These functions are not functions, but #defines.

    One path through the #defines in iperlsys.h has these resolved to:

    #ifdef WIN32 #define PerlDir_mapA(dir) dir #define PerlDir_mapW(dir) dir #endif

    But that can't be right because then they would be unchanged and the problem wouldn't occur.

    The other branch of the #if defined(PERL_IMPLICIT_SYS) in iperlsys.h resolves them to entries in a vtable.

    #ifdef WIN32 #define PerlDir_mapA(dir) \ (*PL_Dir->pMapPathA)(PL_Dir, (dir)) #define PerlDir_mapW(dir) \ (*PL_Dir->pMapPathW)(PL_Dir, (dir)) #endif

    but search high'n'low, I cannot find out where these vtable entries are filled in?

    It appears to be related to PL_curinterp and embedvar.h, but I tracked it back through about 6 levels of indirection before getting completely lost. It will take someone much cleverer than me to resolve this further.


    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
Re^3: -e " " returns true
by BrowserUk (Patriarch) on Jul 06, 2004 at 20:34 UTC

    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
      So let's hope there's a p5p person reading this!

        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
Re: -e " " returns true
by jonadab (Parson) on Jul 06, 2004 at 21:02 UTC
    I found a 1996 article in "Microsoft Systems Journal" which indicates that Win32 does some very odd things with filenames with spaces in them.

    This is no lie. I recommend against using any spaces in filenames on any system (because, they don't gain you anything underscores don't and they complicate things such as the command line unnecessarily), but _especially_ on Win32 (because the capability is retrofitted and imperfect). What gets especially icky is when you have spaces in directory names. Lots of software, including some Microsoft software and almost anything ported to Windows from the POSIX world, fails in some fairly weird ways in certain corner cases involving filenames with spaces. Among other things, the association mechanism in Explorer relies on the command line, but the quoting capabilities there (_especially_ in Win9x/Me) are sufficiently limited to create their own edge cases, so that even if you set up the association with quoted arguments there are still things that can go wrong. The best practice is to avoid putting spaces in any filenames or putting any files in directories with spaces in them. (On WinXP, it's okay to use your "My Documents" folder, but I don't even recommend that on 9x/Me; create your own C:\docs (or whatever) and use that, and you'll have fewer problems.)


    ;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://372039]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (4)
As of 2024-04-26 00:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found