This ignores the possibility of escaping wildcards in bash. For example, say you have a file foo*bar. Someone using your script in bash would do

Bash would replace the \* with *, and pass the script the filename foo*bar. You would then expand the wildcard, and fail to find the file.

Aaah, good point. Perhaps I need to check $^O and do the globbing only on Windows...

bash seems to expand the wildcards into matching filenames before passing them to the perl script

You got the point. In general, UNIX shells expand metacharacters if they find a match.

I don't see anything dangerous in your push, anyway, the glob work under the UNIX shell is useless. You could avoid it using $^O (or $OSNAME if you use English) with a conditional.

I don't know what $OSNAME is under Windogs; assuming it begins with "Windows" you could just do something like:

use English ;

if ($OSNAME =~ /^Windows/i) {
  push @files, glob($_) foreach @ARGV; 
}
[download]

Ciao!
--bronto

# Another Perl edition of a song:
# The End, by The Beatles
END {
  $you->take($love) eq $you->made($love) ;
}

$^O is MSWin32 under Windows (at least recent ones)... unfortunately, as Abigail points out above, using $^O turns out not to be a completely reliable way to determine whether the globbing behavior is safe. To take one simple example, some shells on MSWin32 (Cygwin bash) expand wildcards and others (MS-DOS) don't.

The thing is that I would like to be able to do something that Does What I Mean -- or more precisely, Does What A Potentially Naive User Means. I suspect that somebody who uses DOS/Win and is familiar with commands like copy *.txt \over_here would expect to be able to write munge *.txt and have it do what he'd expect, not report File not found: *.txt.

I suppose one kludgish approach would be to perform the globbing if ($filename =~ /[?*]/ && !-e $filename), for example. Since this particular munging process is non-destructive, there's probably no danger in trying to glob if and only if the filename passed in does not exist. (Yes, I realize that testing for /[?*]/ is a very DOS-centric approach because Unix shells may support more sophisticated wildcarding... this is just a "for example".)

Interesting that this turns out to be a harder problem to solve that it seemed at first. As Abigail says, the real answer is probably to use a globbing vs. a non-globbing shell. I was just hoping there would be a way to make the behavior essentially consistent across platforms and shells without requiring that much thought on the part of a user. (I guess that's what GUIs are for ;-)

Anyway, why shouldn't the Win32 perl kernel resolve this anomaly and make Windows conform to the expected behaviour? (Perl 6? wishlist?)

By the by, VMS implements the globbing via the C runtime library. Command lines themselves are not globbed, but by the time they have become cast into (int argc, char *argv[]) they have been globbed.

My $0.02 --rW

Anyway, why shouldn't the Win32 perl kernel resolve this anomaly and make Windows conform to the expected behaviour?

That would be too hard. There *are* shells available on Windows that do globbing. Furthermore, even on Unix, it's possible to pass in arguments that haven't been subject to shell expansion (for instance, when called with a call from the exec family from C (or in Perl, when exec is called with more than one argument)). Trying to figure out when to do globbing, and when not is bound to get it wrong sometimes.

The bottom line is, if you want globbing, use a globbing shell.

Abigail