Comments for Perl Advent Calendar Entry 11th Dec 2003. Comments posted below may be displayed on perladvent.org.
This doesn't work too well if your platform doesn't use "/" for a path separator. For example, if you're using Windows, you should use "\"
At least on Win32 with ActiveState ActivePerl, chdir('/some/where') works fine. About the only place on Win32 that / doesn't work mix-and-match with \ separators is in the File Open / Save Dialog (and a few other 16-bit hold over system calls; it depends on which file-open API a program uses whether it can accept
However, the idea of @CWD is is so cool, it's still great to see this module! thanks.
Cheers,
Bill
Re:/ Works on Windows
barbie on 2003-12-13T09:30:06
About the only place on Win32 that / doesn't work mix-and-match with \ separators... Plus anytime you use File::Spec with several other modules that require a '/' path delimiter. In fact can anyone who writes module for CPAN, please remember that File::Spec and File::Find are ONLY compatible on Unix like systems. There have been several modules that have failed CPAN testing because of it.
Re:/ Works on Windows
2shortplanks on 2003-12-13T11:04:20
I'm not sure I understand you here Barbie. Are you saying that I shouldn't use File::Spec because some other modules require '/' as a path seperator? Surely it's *those* modules that are broken, not my use of File::Spec.Can you give us some examples of modules that use '/' as path seperators?
Re:/ Works on Windows
barbie on 2003-12-16T10:15:29
File::Spec and File::Find are the most common examples where misunderstandings arise, they most likely happen elsewhere. It's not so much that you can't use them together, it's the fact that care must be taken if your code is to be used on platforms other than Unix style OSs.Say for example you use File::Find to find a list of files, you then store them in a hash as keys. Later you use File::Spec to build a file path, and verify whether the file exists in the hash. On Windows the file will never be found in the hash, as the string comparison of '/' and '\' are different. This is why merlyn's mini-cpan mirror script fails as is on Windows. A minor fix and it works.
Another failing is when people use File::Spec with a file obtained via a web form. File::Spec will work as if the file came from the operating system the server is on. Submit a file from Windows or a Mac onto a Linux box and use File::Spec to disassemble the filename. It won't work as you might expect, as '/' won't be in the path.
As such it is how you *use* File::Spec that is the key, not the module or any other.
Hmmm. I thought it was my that created lexical variables.Unlike my, local creates lexical variables, which means that for any subroutines we call from within that scope will see the new value, i.e. will be in the same directory.
Re:lexical?
2shortplanks on 2003-12-13T11:02:06
indeed, I meant dynamic scoping. Too much editing, and then not properly reading what you actually have wrote.
If one is at the root of the filesystem on *NIX (root of volume on OS's?) Then @CWD is the empty list. However, setting @CWD=(); leaves your process in its current location, at least on Perl 5.8.0 on Linux with File::chdir 0.06.
This, a portable way to get to the top of the directory structure, would be a great feature and it seems that some thought has been given to implementing such a thing. There is a sub CLEAR defined in the package which sets a package variable but the directory position remains unchanged.
Re:Portable chdir('/');
2shortplanks on 2003-12-14T10:52:33
You could always use the rootdir from File::Spec.
use File::Spec::Functions; local $CWD = rootdir;
In all that talk about not changing the current directory for other parts of the program, $/ got stomped on heavily.
All examples should use local $/; instead of $/ = undef;.
--
Hofmator
