http://qs1969.pair.com?node_id=184938

mkmcconn has asked for the wisdom of the Perl Monks concerning the following question:

This is a perlrun Windows question.

On our network, I provide users with several ways to use perl scripts. The most popular method among Windows users has been to convert the script to a batch file, launched with a shortcut on the desktop. The user can then drag an icon or group of icons onto the shortcut, which provides the script with the argument list of files or folders for the operation.

In several of the more complicated scripts, I use Getopt::Long for parsing the options. But, I have discovered that NT4 and Win9x do not properly handle the options, using this method. When the shortcut is launched without arguments, the options are parsed normally. But if the argument list is provided by dropping file or folder icons onto the shortcut, the options are silently ignored.

Options are parsed as expected in Windows 2000 and XP.

My question: Do you know of a way to cause NT4 and Win9x shortcuts to behave the same as Windows 2000?

A little test script follows the READMORE tag, if you have opportunity to try it for yourself.

@rem = '--*-Perl-*--
@echo off
if "%OS%" == "Windows_NT" goto WinNT
perl -x -S "%0" %1 %2 %3 %4 %5 %6 %7 %8 %9
goto endofperl
:WinNT
perl -x -S %0 %*
if NOT "%COMSPEC%" == "%SystemRoot%\system32\cmd.exe" goto endofperl
if %errorlevel% == 9009 echo You do not have Perl in your PATH.
if errorlevel 1 goto script_failed_so_exit_with_non_zero_val 2>nul
goto endofperl
@rem ';
#!/usr/bin/perl -w
#line 15
#testprob.bat

use strict;
use Getopt::Long;

# Print Argument list prior to calling GetOptions
print STDERR join("|", @ARGV), "\n";

my $always      = '';
my $col         = -1;
my $recursive   = '';
my $verbose     = 0;

print STDERR "(GetOptions called here)\n";
GetOptions ('always!'    => \$always,
            'recursive!' => \$recursive,
            'col=i'      => \$col,
            'verbose!'   => \$verbose);
            

# Print Argument list after calling GetOptions
print STDERR join("|", @ARGV), "\n";

wait_close("Process completed\n",4);

sub wait_close{
    my ($warning,
        $timer)    = @_;
    $timer = int($timer) || 2;
    my $i;
    print "$warning\n";
    for ($i=$timer; $i >= 1; $i--){
       print "window will close in $i   \r";
       sleep 1;
    }
    exit;
}
__END__
:endofperl

[download]

In the shortcut to the batchfile, the commandline looks like this: 

\\netshare\testprob.bat --noalways -v -c=3 --recursive

On all Windows versions tested, the output without an argument list is: 
--noalways|-v|-c=3|--recursive
(GetOptions is here)

Process completed

Now, dropping a list of icons onto the shortcut, versions behave differently
Windows 2000 and XP: 

--noalways|-v|-c=3|--recursive|C:\c-media|C:\bin|C:\bats
(GetOptions is here)
C:\c-media|C:\bin|C:\bats
Process completed

NT4 and Win9x: 
C:\c-media|C:\bin|C:\bats
(GetOptions is here)
C:\c-media|C:\bin|C:\bats
Process completed

Note that the options list is never seen by the script. Options are deleted by Windows, and only the argument list is presented to the script.

Can NT4 and Win9x shortcuts be caused to behave the same as Windows 2000?
mkmcconn
edit format and removed typo noticed by BrowserUK

Replies are listed 'Best First'.
Re: Getopts with NT4 and Win9x shortcuts
by BrowserUk (Patriarch) on Jul 24, 2002 at 17:18 UTC

    Probably not very helpful, but one thing I noticed is that in the output on the XP/2000 systems, the subdir C:\cygwin magically appears appended to the post-GetOptions list?

    Are you running cygwin on these systems?

    Not having a XP/2000 system to hand, I don't know which path through early (batch) code these system take. Ie, do they take the :WinNT path or not?

    The different treatment of the parameters (batch) between the 2 paths might have something to do with this?

    Ie.

    perl -x -S "%0" %1 %2 %3 %4 %5 %6 %7 %8 %9

    [download]

    versus

    :WinNT
perl -x -S %0 %*

    [download]

    Maybe a read herring, but it might be interesting to try using the long form for NT and see if that makes a difference?

    Update Looking into this a little further, I added a line @echo %1 %2 %3 ..., as the third line of your .bat/.pl, you'll find that when you drag/drop onto the shortcut, under NT at least, the script doesn't receive any of the command line parameters at all!

    Essentially, the reason is that the filespecs droppped are passed through to the shortcut using DDE, and the command line parameters are essentially ignored. Obviously not very useful and something (on the basis of your evidence) that MS has corrected in NT5 and later.

    The bottom line here is that this is neither a Perl (the language) bug nor a perl (AS) implementation error. It is simply a bug (that is never going to be fixed) in NT4/W95.

    As such, it therefore falls beyond the scope of interest for this forum.

    As for a work-around. When you code the parameters into the shortcut, they are essentially becoming hard-coded defaults to the script. So, the easiest way to do this would be to hardcode them somewhere else.

    Possibilities include:

    • Inside the script: Means you will need several varients of the script.
    • Use an environment var: Same problem, multiple scripts as %0 supplies the name of the script NOT the name of the shortcut.
    • Other: Enquire on a WindowsNT forum for a solution. Sorry.
[reply]
[d/l]
[select]

      ...it therefore falls beyond the scope of interest for this forum.

      I would assume that the issue would be of interest to anyone who wants to run perl on NT or 9x Windows systems, BrowserUK.

      These might not be the OS of preference for you or for me, but in my workplace batch files and CGI deliver Perl solutions to non-perl users all day long. This problem highlights a real limitation of Perl (or any other scripting language) on those operating systems. For that reason, I'd humbly suggest that this is a perlrun FAQ, to which, I think, you have provided a good
      answer:
      The bottom line here is that this is neither a Perl (the language) bug nor a perl (AS) implementation error. It is simply a bug (that is never going to be fixed) in NT4/W95.
      mkmcconn

[reply]

      Thanks for taking a stab at it, BrowserUK.

      • I removed the "C:\cygwin" typo - sorry to confuse.
      • Changing the batch parameter lines does not change the behavior of the shortcut.
      • Windows 2000 environment variable, %OS%, expands to "Windows_NT".
      • Answer not found, yet.

      mkmcconn
      fiddled with text after post
[reply]

Back to Seekers of Perl Wisdom