Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
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: (8)
As of 2014-12-26 15:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (171 votes), past polls