Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

UNC vs. standard Perl functions

by crenz (Priest)
on Mar 16, 2005 at 14:48 UTC ( #439960=perlquestion: print w/ replies, xml ) Need Help??
crenz has asked for the wisdom of the Perl Monks concerning the following question:

I have a Perl script on Windows that needs to access files using UNC paths. However, I am getting weird results (using Perl 5.8.6):

C:\>perl -e "print -d 'C:\Windows'" 1 C:\>perl -e "print -d 'C:/Windows'" 1 C:\>perl -e "print -d '\\server\share'" C:\>perl -e "print -d '//server/share'" 1

So locally, I can use either slashes or backslashes. Via UNC, however, I can only use slashes. That is weird in itself, but really annoying considering this behaviour:

C:\>perl -MFile::Spec::Functions -e "print catfile('//test/dir', 'test +2');" \\test\dir\test2

Which means my platform-independant script that uses catfile/catdir suddenly doesn't work on Windows with UNC paths. If I would have done stuff manually with my $name = "$dir/$file", I'd be fine now :-(.

Is this considered a bug in Perl, or a bug in File::Spec::Functions?

Comment on UNC vs. standard Perl functions
Select or Download Code
Re: UNC vs. standard Perl functions
by ikegami (Pope) on Mar 16, 2005 at 14:55 UTC
    >perl -e "print '\\server\share'" \server\share

    Don't you mean

    >perl -e "print '\\\\server\\share'" \\server\share >perl -e "print -d '\\\\server\\share'" 1

    Remember,
    \ and ' must be espcaped with \ in single-quoted string literals.
    \ and ", $ and @ must be espcaped with \ in double-quoted string literals.

      I'm hitting myself now. Thanks, I forgot about that. I was so very convinced you don't have to quote \ in '' strings...

        You don't, unless you want to have two of them together.
      Actually, double-\\ in a single-quoted string is interpreted as a single \ but otherwise \ does not need to be escaped. So this also works:
      perl -e "print -d '\\\\server\share'"

        True. Stylisticly, I prefer to escape them all, so I don't have to look at the context to know what \n means (for example). Adopting that convention would have avoided the OP's problem.

Re: UNC vs. standard Perl functions
by brian_d_foy (Abbot) on Mar 16, 2005 at 18:40 UTC

    It's not a bug in Perl, and it's not a bug in File::Spec::Functions: it's documented (and intended) behavior.

    At the beginning of File::Spec, it looks at the value of $^O to see which operating system it's on, then selects an appropriate subclass. On Windows, that's File::Spec::Win32, and in that module it defines the directory separator.

    You want it to pick something else. You could add a subclass for UNC so the module handles the root directory and other things correctly, or you can make File::Spec think that it's on another system. I sometimes need to do this to work with paths from other systems without turning them into UNIX paths.

    #!/usr/bin/perl BEGIN { local $^O = 'MSWin32'; # or Unix MacOS VMS, and so on require File::Spec::Functions; File::Spec::Functions->import; } my $path = catfile( 'top', 'middle', 'bottom' ); print $path, "\n";

    I run this on FreeBSD and get "top\middle\bottom".

    --
    brian d foy <bdfoy@cpan.org>

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://439960]
Approved by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (13)
As of 2014-07-23 09:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (138 votes), past polls