Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Re: CGI troubles for code that runs on both Windows and OpenSuse Linux 12,3

by taint (Chaplain)
on Dec 20, 2013 at 06:38 UTC ( #1067920=note: print w/replies, xml ) Need Help??

in reply to CGI troubles for code that runs on both Windows and OpenSuse Linux 12,3

Greetings, ted.byers.

There's a couple of ways you can manage this

#!/home/ivan/bin/perl #!/usr/bin/perl
Another might be
#!/usr/bin/env perl
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 +t 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 +r 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 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 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

Yes. What say about me, is true.

Replies are listed 'Best First'.
Re^2: CGI troubles for code that runs on both Windows and OpenSuse Linux 12,3
by ww (Archbishop) on Dec 20, 2013 at 15:17 UTC
    Irrelevant to any diff between Win and *nix behavior; wrong, and another instance of taint diving down a rabbit hole while chasing a giraffe.

    Quis custodiet ipsos custodes. Juvenal, Satires

      Off base, ww. Applies directly to 1). in the OP.
      Yes. What say about me, is true.
        While ww, and I clearly have a disagreement on some of the details here. To ww's credit, I would like to offer the following link Windows NT/200x/XP and Windows 9x/Me for further consideration.

        Thanks, ww. Even if we don't completely agree. ;)


        Yes. What say about me, is true.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1067920]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (4)
As of 2018-06-23 13:04 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (125 votes). Check out past polls.