trying to launch a second CGI, from a parent CGI

[erik]

sub odie_qa_integration{
print `/var/apache/cgi-bin/odie-qa.p­l device=$device`;
}


VIA A BROWSER: I can 'execute' the child CGI just fine, I just can't
seem to pass the $device variable to it. Actually I can't pass anything
to it. If I change $device to a static device name, meaning not a
scalar, it still does not work. So anything I pass to it gets lost.

VIA SHELL: Everything works great. The parent CGI passes device info to
the child CGI script just fine.

This has baffled me, can anyone help? I would greatly appreciate any
help.

 

[Gunnar Hjalmarsson]

sub odie_qa_integration{
print `/var/apache/cgi-bin/odie-qa.p­l device=$device`;
}

VIA A BROWSER: I can 'execute' the child CGI just fine, I just can't
seem to pass the $device variable to it. Actually I can't pass anything
to it. If I change $device to a static device name, meaning not a
scalar, it still does not work. So anything I pass to it gets lost.

VIA SHELL: Everything works great. The parent CGI passes device info to
the child CGI script just fine.

Have you tried to call the Perl interpreter explicitly?

print `perl /var/apache/cgi-bin/odie-qa.p­l device=$device`;
-----------^^^^

Do you know the difference between command line arguments and CGI
parameters?

 

[erik]

I appreciate you looking at this issue gunnar. The she bang works
great, as I said it executes just fine.

Do you know the difference between command line arguments and CGI
parameters?

I do. You know how when you test a CGI app via CLI, you pass it each
variable, such as device="ewitkop.home.com", and so on. That is how I
am trying to launch the child script from the parent.

Please note I have also tried:

system ("/var/apache/cgi-bin/odie-qa.pl device=$device");

and the qx variety. Nothing works when using the browser.

 

[erik]

I should also note, that I have CGI standard on.

use Expect;
use CGI(":standard");
use DBI;
$Expect::Log_Stdout = 0;
$device = param("device");
$username = param("username");
$password = param("password");
$protocol = param("protocol");

 

[Gunnar Hjalmarsson]

I appreciate you looking at this issue gunnar.

Which issue?

Please provide context, typically by quoting a part from the message you
reply to. More about that (and other useful info) can be found in the
posting guidelines for this group:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html

You didn't answer that question.

when you test a CGI app via CLI, you pass it each
variable, such as device="ewitkop.home.com", and so on. That is how I
am trying to launch the child script from the parent.

Sorry, I don't understand. Maybe it's me.

Anyway, I recommend that you post a *short* but *complete* child script
that illustrates the problem. Doing so will increase your chances to get
help.

 

[Sherm Pendley]

erik wrote:

Sorry, I don't understand. Maybe it's me.

CGI.pm reads input from command-line arguments when it doesn't see any of the
standard CGI variables in its environment.

When you launch a child script, it inherits its environment from its parent;
since the parent in this case is a CGI, the child inherits the standard CGI
variables. So CGI.pm tries to read form data as it would when running as a CGI,
instead of reading them from the command-line arguments you've given.

I can think of several potential ways to work around this. You could encode
the form data and feed it to the child's stdin, just like the web server would.
You could use LWP to submit a separate request to the web server and fetch the
results of that request. You could delete whatever environment variable is
triggering CGI.pm's "CGI mode" before launching the child process.

That last seems like it would be the easiest to implement - just delete the
appropriate element from %ENV. But, figuring out which of the several CGI
variables you want to delete might be a hassle.

sherm--

 

[Sherm Pendley]

Thanks for an excellent explanation, Sherm. However, please consider
this example:

C:\>type test.pl
#!/usr/bin/perl
use CGI;
my $q = CGI->new;
print "Parameter: ", $q->param('var') || '(none)', "\n";

C:\>test.pl var=hello
Parameter: (none)

C:\>perl test.pl var=hello
Parameter: hello

C:\>

The sets of environment variables are identical in those two cases...

I see from the C:\> prompt that you're running Windows. The results you're
getting might have something to do with how Windows runs .pl scripts - I
think it uses the extension to open the script with the associated app. The
environment might be getting lost in the shuffle when that happens.

It's been a while since I've used Windows though - I could be wrong. At any
rate, I get the same results both ways under Linux:

sherm@debian:~$ cat test.pl
#!/usr/bin/perl
use CGI;
my $q = CGI->new;
print "Parameter: ", $q->param('var') || '(none)', "\n";
sherm@debian:~$ ./test.pl var=hello
Parameter: hello
sherm@debian:~$ perl test.pl var=hello
Parameter: hello

I had a look in CGI.pm, and it looks like the REQUEST_METHOD variable is what
it's looking for, as shown here:

sherm@debian:~$ export REQUEST_METHOD=GET
sherm@debian:~$ ./test.pl var=hello
Parameter: (none)
sherm@debian:~$ perl test.pl var=hello
Parameter: (none)

So, to the OP, try this:

my $old_rm = $ENV{'REQUEST_METHOD'}; # Save and restore it just to be safe...
delete $ENV{'REQUEST_METHOD'};
system 'some_other.cgi param=value';
$ENV{'REQUEST_METHOD'} = $old_rm;

Saving and restoring the previous value is probably not actually necessary. I
put it in there just to be on the safe side. If you're feeling adventurous you
might try skipping that.

sherm--

 

[Gunnar Hjalmarsson]

CGI.pm reads input from command-line arguments when it doesn't see any of the
standard CGI variables in its environment.

When you launch a child script, it inherits its environment from its parent;
since the parent in this case is a CGI, the child inherits the standard CGI
variables. So CGI.pm tries to read form data as it would when running as a CGI,
instead of reading them from the command-line arguments you've given.

I can think of several potential ways to work around this. You could encode
the form data and feed it to the child's stdin, just like the web server would.
You could use LWP to submit a separate request to the web server and fetch the
results of that request. You could delete whatever environment variable is
triggering CGI.pm's "CGI mode" before launching the child process.

That last seems like it would be the easiest to implement - just delete the
appropriate element from %ENV.

Thanks for an excellent explanation, Sherm. However, please consider
this example:

C:\>type test.pl
#!/usr/bin/perl
use CGI;
my $q = CGI->new;
print "Parameter: ", $q->param('var') || '(none)', "\n";

C:\>test.pl var=hello
Parameter: (none)

C:\>perl test.pl var=hello
Parameter: hello

C:\>

The sets of environment variables are identical in those two cases...

 

[A. Sinan Unur]

I see from the C:\> prompt that you're running Windows. The results
you're getting might have something to do with how Windows runs .pl
scripts - I think it uses the extension to open the script with the
associated app. The environment might be getting lost in the shuffle
when that happens.

I think the issue here is what happens to STDIN rather than the
environment:

D:\Home\asu1\UseNet\clpmisc> perl ttt.pl < ttt.pl
#!/usr/bin/perl

print while <> ;

__END__

versus

D:\Home\asu1\UseNet\clpmisc> ttt < ttt.pl

I remember this being mentioned here in various contexts.

On the other hand, I think the OP needs to realize that the script he is
calling using backticks is not really being called as a CGI script, and
that he can read the arguments to that script through @ARGV.

Sinan

 

[gimme_this_gimme_that]

Wouldn't this work?

print "Location : $homeCGI/otherPerlScript.pl?$device=some_device";

 

[Sherm Pendley]

Wouldn't this work?

Work for what? You haven't quoted the context that most folks would need to
understand what you're referring to. Fortunately(?) for you, I've posted
recently to this thread and I remember what it's about.

print "Location : $homeCGI/otherPerlScript.pl?$device=some_device";

The OP doesn't want to redirect the user's browser to a new location, he
wants to launch a child CGi script and include its output along with the
parent.

sherm--

 

[Sherm Pendley]

I think the issue here is what happens to STDIN rather than the
environment:

How could that possibly be the issue when the examples don't take any input
at all from stdin? Although yes, I mistyped that - the command-line arguments
are being lost, not the environment.

On the other hand, I think the OP needs to realize that the script he is
calling using backticks is not really being called as a CGI script, and
that he can read the arguments to that script through @ARGV.

The CGI.pm module, when run from a command line for debugging, accepts input
by way of @ARGV. There's no reason why the OP can't use that feature, except
that CGI.pm thinks it's being run as a CGI, not from a command line. It thinks
that because it's seeing REQUEST_METHOD in the environment it inherits from its
parent, which really is being run as a CGI.

sherm--

 

[erik]

I didn't try that gimme, but I got my solution working late last night.
Sherm's post (all of them) are dead on. And Gunnar has the right idea
by asking to see more of the child script to see how it is setup.

Here is what I did to fix it. The child script defined $device as a
"param", meaning CGI. I change $device of the child script to a basic
ARGV[0]. After I did that, the parent CGI had no issue passing the
$device to it. Now you are thinking "well you broke the CGI feature of
the child script because you need a param." I simply made a copy of
the child CGI and editing $device so the parent will always call that
specifically made child.

I thought my original solution should have worked. But Sherm explained
why it doesn't work and I learned something here. Thanks guys.

 

[erik]

Sinan, I missed your last paragraph.

"On the other hand, I think the OP needs to realize that the script he
is
calling using backticks is not really being called as a CGI script, and

that he can read the arguments to that script through @ARGV."

You got it man! Thanks.

 

[Fabian Pilkowski]

Curious. My Windows/Perl is doing some different with exactly the same
"test.pl".

D:\home> test.pl var=hello
Parameter: hello
D:\home> perl test.cgi var=hello
Parameter: hello

Btw, I'm using WindowsXP SP2, ActiveState's Perl 5.8.6 and CGI.pm 3.05.

At any rate, I get the same results both ways under Linux:

And that's what I get under windows too.

I had a look in CGI.pm, and it looks like the REQUEST_METHOD variable is what
it's looking for, as shown here:

sherm@debian:~$ export REQUEST_METHOD=GET
sherm@debian:~$ ./test.pl var=hello
Parameter: (none)
sherm@debian:~$ perl test.pl var=hello
Parameter: (none)

Same under Windows.

D:\home> set REQUEST_METHOD=GET
D:\home> test.pl var=hello
Parameter: (none)
D:\home> perl test.pl var=hello
Parameter: (none)

So, to the OP, try this:

my $old_rm = $ENV{'REQUEST_METHOD'}; # Save and restore it just to be safe...
delete $ENV{'REQUEST_METHOD'};
system 'some_other.cgi param=value';
$ENV{'REQUEST_METHOD'} = $old_rm;

Saving and restoring the previous value is probably not actually necessary.

Especially not necessary to do this by hand. Localizing will work for a
single hash key (or array element) as well. I prefer

{
local $ENV{REQUEST_METHOD};
system( 'test.pl var=hello' );
}

Btw, first I tried to assign *undef* to this localized hash key, but
this gives a (doubled) warning like:

D:\home> perl -we "$ENV{R}=undef"
Use of uninitialized value in scalar assignment at -e line 1.
Use of uninitialized value in scalar assignment at -e line 1.

I have never seen this warning before. What it Perl doing here? `perldoc
perldiag` says to this type of warning:

An undefined value was used as if it were already defined. It was
interpreted as a "" or a 0, but maybe it was a mistake. [...]

But as one could check easily, Perl don't use "" or 0 here, it assigns
undef as desired.

D:\home>perl -we "$ENV{R}=undef;print$ENV{R}"
Use of uninitialized value in scalar assignment at -e line 1.
Use of uninitialized value in scalar assignment at -e line 1.
Use of uninitialized value in print at -e line 1.

Is seems this is something special with %ENV, but I see nothing about
this in `perldoc perlvar`.

regards,
fabian

 

[Henry Law]

I

Would you Google Groups merchants PLEASE learn to include some
context? This stuff looks like random pages from someone's
waste-paper bin and I'm inclined to start treating it as such.

 

[A. Sinan Unur]

How could that possibly be the issue when the examples don't take any
input at all from stdin? Although yes, I mistyped that - the
command-line arguments are being lost, not the environment.

Yes! It is all your fault!

Seriously, though, there must have been a short circuit somewhere in my
brain. I think I posted this about the same time as the double reverse.

Thanks for the correction.

Sinan

 

[Gunnar Hjalmarsson]

The CGI.pm module, when run from a command line for debugging, accepts input
by way of @ARGV. There's no reason why the OP can't use that feature,

The fact that the feature is intended for debugging of CGI scripts may
be such a reason. Is it good practice to use a debugging feature in a
production solution? Even if it's documented behaviour, is it advisable
to trust that it won't be altered in future versions?

Note that the OP confirmed Sinan's theory:
http://groups-beta.google.com/group/comp.lang.perl.misc/msg/6355e7c579057a27

 

[A. Sinan Unur]

The fact that the feature is intended for debugging of CGI scripts may
be such a reason. Is it good practice to use a debugging feature in a
production solution? Even if it's documented behaviour, is it
advisable to trust that it won't be altered in future versions?

I agree with your objection to using a debugging feature as a production
solution. At the very least, it means that the programmer did not
understand fully what he/she was doing.

On the other hand, I would like to point out that you were the first one
to point out what was going (albeit, as a question):

<URL:http://groups-
beta.google.com/group/comp.lang.perl.misc/msg/e20c3b56bc28b843>

Note that the OP confirmed Sinan's theory:
http://groups-
beta.google.com/group/comp.lang.perl.misc/msg/6355e7c579057a27

Thanks for bringing that to my attention. I went on a killfile rampage
last week after getting egg on my face in comp.lang.c, and no longer see
postings from Google Groups. I can see erik is still refusing to quote
context.

Sinan

 

[Gunnar Hjalmarsson]

Curious. My Windows/Perl is doing some different with exactly the same
"test.pl".

D:\home> test.pl var=hello
Parameter: hello
D:\home> perl test.cgi var=hello
Parameter: hello

Btw, I'm using WindowsXP SP2, ActiveState's Perl 5.8.6 and CGI.pm 3.05.

I have the same environment, except that I got Perl from IndigoPerl.

Can't explain why the results differ; have been using XP less than a
week. ;-)