#!/bin/bash
export GATEWAY_INTERFACE='CGI/1.1'
export REQUEST_METHOD='GET'
export PATH_INFO='/extra/path/elements'
export QUERY_STRING='name1=value1&name2=value2'
exec /srv/www/cgi-bin/some.cgi
batch:
@echo off
set GATEWAY_INTERFACE="CGI/1.1"
set REQUEST_METHOD="GET"
set PATH_INFO="/extra/path/elements"
set QUERY_STRING="name1=value1&name2=value2"
perl C:\srv\www\cgi-bin\some.cgi
Note that this assumes the CGI is a perl script. For a CGI *.exe file, the batch file should look like this:
@echo off
set GATEWAY_INTERFACE="CGI/1.1"
set REQUEST_METHOD="GET"
set PATH_INFO="/extra/path/elements"
set QUERY_STRING="name1=value1&name2=value2"
C:\srv\www\cgi-bin\some-cgi.exe
Also note that there is a minor difference: The bash file replaces itself with the CGI after modifying the environment (that's what exec does), the batch file just runs the CGI as a subprocess. That's simply because Windows has neither exec nor fork. (Windows perl versions implement fork and exec as emulations, but they are far from the original.)
If the CGI is a perl script, you can use the perl wapper script as well, even on Windows, with a little modification: Replace the final line exec('/srv/www/cgi-bin/some.cgi') or die "exec failed: $!"; with do 'c:\srv\www\cgi-bin\some.cgi';. This will load the CGI script into the wrapper script, running it in the same process as the wrapper. See do.
Note that the wrapper script and the CGI script share the same namespace here, so the names of routines and variables may collide (sub encode and my @pairs in my example). If that is a problem, rename the variables and/or routines or consider moving the setup into a module.
One final thing: "Perl" is the name of the language. "perl" is the name of the implementation. "PERL" is just nonsense.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
|