in reply to
CGI troubles for code that runs on both Windows and OpenSuse Linux 12,3
There's a couple of ways you can manage this
Another might be
As you can see in the first example. There are 2 shebangs. In your case, it's simply a matter of providing the paths to Perl on both your boxes/environments. In the second example. It uses the (ENV)vironment's search path to discover Perl's location.
UPDATE: It was late (for me) when I wrote this. So I didn't take the time to look up information that I knew was available since ~5.005. For completeness
I'll add it here (from REAME.win32)
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 no
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 MakeMake
support. This bundle is available at:
See the README in that distribution for building and installation
instructions. Look for later versions that may be available at the
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
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:
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
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:
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.
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
Yes. What say about me, is true.