except that it breaks DOS machines.
DOS/Windows coders can get their revenge by using

That would be revenge indeed, creating a program which will run nowhere, not even on windows. On seeing this code perl turns it into:

Which is unlikely to be the file you wanted to open. Always, always, always, use '/' as a directory seperator, it works all over the place. In fact, your first versuion:

open (FH, ">/temp/tempfile");
print FH $temporary_data;
[download]

will work perfectly well, assuming 'C:\temp\tempfile' exists, but you didn't check the sucess of the open call so you'll never know.

Always, always, always, use '/' as a directory seperator, it works all over the place.

Unless, of course, you're on a Mac (where the directory separator is ':'), or some other operating system with a different directory separator. :)

Unless, of course, you're on a Mac (where the directory separator is ':'), or some other operating system with a different directory separator. :)

If you're really worried about the directory separator, do this:

$dir_separator='/';
open BLARG, "$dir_name$dir_separator$file_name";
[download]

I can't really explain why, but sticking directory separators in a file name makes me cringe. I guess it's because the separator is not a part of the file name.

There, I guess I did explain why.

Excellent - I see you spotted my deliberate mistake :) If you put single quotes around it though, it works fine:


open FH, '>c:\temp\tempfile';
[download]


the extra comma and greater-than sign help too.

The main point still stands - hard coding filenames through your code is not a good idea. I don't know whether it is such a great idea to "Always, always, always, use '/' as a directory separator" or not. I feel it's fine to use whichever directory separator is appropriate for your filing system, just don't hard-code it.

I'm not checking for errors or the like, because I was pitching the article at perl programmers who are competent, but who may not have programmed on more than one platform. As such I would be expecting them to be doing all sorts of neat stuff, but perhaps overlooking basic portability issues because they've never needed to address them before.

____________________
Jeremy
I didn't believe in evil until I dated it.

I have to strongly disagree with your first point. You just need to fix your copy of Perl to expand wildcards. It sucks that ActiveState doesn't make this easy, but there are instructions in one of the FAQs. Actually, I just stuff a @ARGV=map{glob($_)}@ARGV if $^O=~/^MSWin/; at the front of scripts that take a list of file names.

It would really suck if people started following your specific advice of hardcoding <*> so that scripts could never be run on a subset of files or files from more than one directory.

See File::Spec for more advice on making scripts portable.

-- Randal L. Schwartz, Perl hacker

• you dont offer any way to actually detect which operating system we're running on and should be friendly enough to support
• you dont cover any other operating system. its a little known fact that there are in fact more than two major operating systems out there. I'm curious to know what MacPerl does whether it converts file/path/ to file:path: or it actually needs colons.

I am actually currently involved in making cross-platform code and would be interested to know more about making things more windows and mac-friendly.

one last note:

open (FH, ">/temp/tempfile");
print FH $temporary_data;
[download]

dep.

--
i am not cool enough to have a signature.

I'm curious to know what MacPerl does whether it converts file/path/ to file:path: or it actually needs colons.

MacPerl does not convert 'file/path/' to 'file:path:'; one must actually use colons in the paths.

Even trickier, however, is the way of specifying relative paths, by prepending the directory separator. On a Mac, ':mammal:dog' means the file dog in the directory mammal in the current working directory, whereas on Unix '/mammal/dog' means the file dog in the directory mammal in the root directory.

On the other hand, the path 'animal:mammal:dog' on a Mac means the file dog in the directory mammal in the root directory of the volume animal. On Unix 'animal/mammal/dog' means the file 'dog' in the directory 'mammal' in the directory 'animal' in the current working directory.

Here's a script that demonstrates this behavior in MacPerl:

  use Cwd;

  print cwd(), "\n";

  -e 'foo' or mkdir('foo', 0777) or die "Can't mkdir 'foo': $!\n";

  open(FH, '>foo/bar') or warn "Can't open 'foo/bar': $!\n";
    # creates a file named 'foo/bar' in cwd

  open(FH, '>foo:bar') or warn "Can't open 'foo:bar': $!\n";
    # fails, unless you actually have a volume named 'foo'
    # in that case, creates a file named 'bar' on the volume 'foo'

  open(FH, '>:foo:bar') or warn "Can't open ':foo:bar': $!\n";
    # creates a file named 'bar' in the directory 'foo' in the cwd
[download]

Getting cross-platform file paths is not an easy problem. That's why the File::Spec module was created. (Except that all the documentation for the module is in File::Spec::Unix. You'll have to read it locally.)

Yes, you are quite correct. However my point wasn't to start up a new module war, just to point out how with a few smallish changes that are pretty much good programming practise anyway, that code can made cross-platform. I felt that saying someone should go and learn Yet Another Module would be a bit too much (does anyone else dread the task of reading through the docs for all modules related to a task, then trialling them all to see which ones work well?)

Update: chipmunk pointed out that '/' is not a directory separator for every good port - the Mac does things differently.

____________________
Jeremy
I didn't believe in evil until I dated it.