#!/home/ivan/bin/perl
#!/usr/bin/perl

##</code><code>##

#!/usr/bin/env perl

##</code><code>##

Win32 Specific Extensions

A number of extensions specific to the Win32 platform are available
from CPAN.  You may find that many of these extensions are meant to
be used under the Activeware port of Perl, which used to be the only
native port for the Win32 platform.  Since the Activeware port does not
have adequate support for Perl's extension building tools, these
extensions typically do not support those tools either, and therefore
cannot be built using the generic steps shown in the previous section.

To ensure smooth transitioning of existing code that uses the
ActiveState port, there is a bundle of Win32 extensions that contains
all of the ActiveState extensions and most other Win32 extensions from
CPAN in source form, along with many added bugfixes, and with MakeMaker
support.  This bundle is available at:

   http://www.cpan.org/authors/id/GSAR/libwin32-0.151.zip

See the README in that distribution for building and installation
instructions.  Look for later versions that may be available at the
same location.

item Running Perl Scripts

Perl scripts on UNIX use the "#!" (a.k.a "shebang") line to
indicate to the OS that it should execute the file using perl.
Win32 has no comparable means to indicate arbitrary files are
executables.

Instead, all available methods to execute plain text files on
Win32 rely on the file "extension".  There are three methods
to use this to execute perl scripts:

over 8

item 1

There is a facility called "file extension associations" that will
work in Windows NT 4.0.  This can be manipulated via the two
commands "assoc" and "ftype" that come standard with Windows NT
4.0.  Type "ftype /?" for a complete example of how to set this
up for perl scripts (Say what?  You thought Windows NT wasn't
perl-ready? :).

item 2

Since file associations don't work everywhere, and there are
reportedly bugs with file associations where it does work, the
old method of wrapping the perl script to make it look like a
regular batch file to the OS, may be used.  The install process
makes available the "pl2bat.bat" script which can be used to wrap
perl scripts into batch files.  For example:

	pl2bat foo.pl

will create the file "FOO.BAT".  Note "pl2bat" strips any
.pl suffix and adds a .bat suffix to the generated file.

If you use the 4DOS/NT or similar command shell, note that
"pl2bat" uses the "%*" variable in the generated batch file to
refer to all the command line arguments, so you may need to make
sure that construct works in batch files.  As of this writing,
4DOS/NT users will need a "ParameterChar = *" statement in their
4NT.INI file, or will need to execute "setdos /p*" in the 4DOS/NT
startup file to enable this to work.

item 3

Using "pl2bat" has a few problems:  the file name gets changed,
so scripts that rely on $0 to find what they must do may not
run properly; running "pl2bat" replicates the contents of the
original script, and so this process can be maintenance intensive
if the originals get updated often.  A different approach that
avoids both problems is possible.

A script called "runperl.bat" is available that can be copied
to any filename (along with the .bat suffix).  For example,
if you call it "foo.bat", it will run the file "foo" when it is
executed.  Since you can run batch files on Win32 platforms simply
by typing the name (without the extension), this effectively
runs the file "foo", when you type either "foo" or "foo.bat".
With this method, "foo.bat" can even be in a different location
than the file "foo", as long as "foo" is available somewhere on
the PATH.  If your scripts are on a filesystem that allows symbolic
links, you can even avoid copying "runperl.bat".

Here's a diversion:  copy "runperl.bat" to "runperl", and type
"runperl".  Explain the observed behavior, or lack thereof. :)
Hint: .gnidnats llits er'uoy fi ,"lrepnur" eteled :tniH