try running perldoc perlport, you'll find information on all kinds of special variables and porting gotchas.

by the way, $^O aka $OSNAME gives you the name of your OS.

~Particle

Nor should you expand wildcards if the user bypassed wildcard expansion on purpose.... (quoting, escaping, direct exec call instead of going via a shell, etc).

It's going to be very, very hard to be "portable" here.

-- Abigail

I didn't say "for complete, 100% portablitity to all possible situations". That line makes the code more portable, which is all that I was claiming.

I think that most users of Unix-like shells on Windows will be using Cygwin Perl which doesn't report $^O as "MSWin32" (especially since using "native Win32" Perl with Cygwin shells has at least a few minor issues).

Also, under Win32, characters like "*" can't be put into file names even if you quote them so the problems with "over glob()ing" under Win32 are smaller than they are for Unix (where they are quite small anyway for most cases -- so I don't suggest you put this code in scripts whose command lines demand a lot of quoting under Unix).

Default Win32 shells/programs don't bypass wildcarding via quoting (in part because the shell doesn't wildcard, in part because the quoting schemes are quite lame, and in part because how to handle spaces in file names was not well thought out), so the only problem is determining the shell.

But I find just checking $^O to be an acceptable level of portability considering how trivial the check is.

I think I'd rather have "native Win32" Perl glob() its command-line arguments by default (like it used to years ago) so that solving this inside the script wouldn't be as attractive -- I see no reason to create extra porting problems for Perl scripts. /: [and add Win32::GetCommandLine() into the base perl.dll for Win32-specific scripts to use, which should cover the only motivation I think of for the current behavior]

        - tye (but my friends call me "Tye")