Re: open file error

[jellisii2]

I would also suggest use of File::Spec for building out path names. I don't know that it would have cleaned up your variable or not, but its a good habit to use it when assembling paths.

That said, I may be one of those weirdos that has had to write code that works on multiple platforms and been bitten by this. :)

[afoken]

File::Spec makes two assumptions:

1. File system rules depend only on the operating system
2. A set of file system rules choosen for an operating system is valid for all mounted file systems.

Both assumptions are wrong at least for Linux (see "Filesystem Specific Mount Options" in mount(8)), probably all modern Unix derivates, and so File::Spec can return wrong results.

See also Re^5: Unify windows filenames.

Alexander

[RonW]

It has been a long time since I've had to write a Perl program that had to support an OS other than Linux/Unix/POSIX, MS Windows and Mac OSX.

Internally, MS Windows accepts / as a path separater. It is cmd.exe that has a problem because it treats / as the option introducer. So, c:/path/to/file or even c:\path\to/file are valid.

Of course, Linux/etc and Mac OSX don't use volume designaters ("drive letters"), so would try to treat "c:" as a directory in the current directory, but, so far, in the Perl programs I've written, the only source of volume designaters is from user input (either directly or through a file dialog box).

In the rare case I have to start cmd.exe from Perl, I have used File::Spec::canonpath to insure the file path is acceptable.

Otherwise, I usually treat file paths as POSIX style and have no problems.

For example, to split a path, I just use

@dirs = split qr{[\\/]}, $path;
$file = pop @dirs unless -d $path;

And to assemble a path

$path = '/' . join '/', @dirs, ($file // '');

Mostly, I don't care about the volume. If I need it, it's in $dirs[0].