Re: Script Arguments and Wildcard Expansion under Windows NT

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

Comment on Re: Script Arguments and Wildcard Expansion under Windows NT Download Code

Replies are listed 'Best First'.
(tye)Re2: Script Arguments and Wildcard Expansion under Windows NT by tye (Sage) on Jun 28, 2001 at 22:59 UTC
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")	[reply]

Replies are listed 'Best First'.

(tye)Re2: Script Arguments and Wildcard Expansion under Windows NT
by tye (Sage) on Jun 28, 2001 at 22:59 UTC

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

[reply]