Re: portable globbing behavior for command-line tool

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) ;
}

Comment on Re: portable globbing behavior for command-line tool Select or Download Code

Replies are listed 'Best First'.
Re: Re: portable globbing behavior for command-line tool by seattlejohn (Deacon) on Jul 04, 2002 at 17:40 UTC
`$^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 ;-)	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: portable globbing behavior for command-line tool
by seattlejohn (Deacon) on Jul 04, 2002 at 17:40 UTC

$^O

MSWin32

$^O

MSWin32

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

[reply]
[d/l]
[select]