Your problem is that Unix expands wildcards before passing them to the program. Windows doesn't do this, prefering to let the program carry out it's own wildcard expansion.

You could get round it by adding another loop and using the glob operator.

foreach my $glob (@ARGV) {
  foreach my $file (<$glob>) {
    print("converting $file...");
    open(FILE, "<$file");
    my @lines = <FILE>;
    close(FILE);
[download]

Update: Abigail is right. I should have said "The default Windows shell doesn't do this".

Perl Training in the UK <http://www.iterative-software.com>

Actually, it isn't a Unix vs NT thing. Wildcard expansion is done by the shell. Typical Unix shells, like sh, csh, ksh, bash, tcsh and zsh all do wildcard expansion. Several of those shells have been ported to the Windows environment. They should do wildcard expansion there as well.

-- Abigail

Excellent, thank you very much! You solved my problem and I learned about "globbing" for the first time -- another step on the road to sainthood.

Just add @ARGV= map glob, @ARGV; near the top of your script. For portability, you can do: @ARGV= map glob, @ARGV   if  $^O =~ /^MSWin/;

Ah, I was wondering about portability for this; thanks! Your solution works great and I am very pleased, but I've never used $^0 before and I can't seem to find anything about it when I search. How does it work?

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

Actually, for portability, it might be better to check what shell is being used than what platform - you shouldn't expand wildcards if you are running the Korn Shell under Windows.

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")

--
RatArsed