Problem with one perl script executing another, execution started byApache httpd

T

Ted Byers

Using the latest IndigoPerl, I have two scripts that do not behave
alike. Both are in the perl-bin directory of the Apache server
distributed with IndigoPerl.

The first one appended below works fine. It shows the output from a
perl script located in a directory tree completely outside the
directory tree for IndigoPerl, as well as a system command (this is
Windows XP). I get the expected output by providing the URL "http://
localhost/perl-bin/format_test.pl" to the browser.

The second one just hangs, displaying the initial text, but the script
appears to stop at the point where TedsMakeNewPortfolios.pl is
invoked. it is as if an attempt is made to run my scrpt, and control
is never returned to the main script. Yes, an association between
perl and the 'pl' extension has been created, and if I invoke
TedsMakeNewPortfolios.pl from the commandline (e.g. using
"TedsMakeNewPortfolios.pl 522"), it works flawlessly. So why isn't my
TedsMakeNewPortfolios.pl being executed?

The ONLY difference I can see is that my script takes a commandline
parameter and the printenv_segment.pl does not, but I don't see why
that would be significant. I will run a test, though, assigning "C:\
\yohan\\PRODUCTION\\MakeNewPortfoliosETF\\TedsMakeNewPortfolios.pl
$id" to a local variable before trying to execute it, to see if that
makes a difference. But suggestions on how to get this to work would
be appreciated.

Thanks

Ted

======format_test.pl=================
#!c:/perl/bin/perl.exe
use strict;
use CGI qw/:standard/;
my $name = param('name');
my $id = param('id');

print <<"END";
Content-type: text/html

<HTML><HEAD>
<TITLE>Arrays</TITLE>
</HEAD>

<BODY>
END

my $a = 0.0550001;
my $b = 150.3449;
my $c = 1158.435;
my $mc = -1158.435;
my $d = 100256147.258;

my $rv1a = sprintf("%.2f",$a);
my $rv1b = sprintf("%.2f",$b);
my $rv1c = sprintf("%.2f",$c);
my $rv1mc = sprintf("%.2f",$mc);
my $rv1d = sprintf("%.2f",$d);

my $rv2a = commify($rv1a);
my $rv2b = commify($rv1b);
my $rv2c = commify($rv1c);
my $rv2mc = commify($rv1mc);
my $rv2d = commify($rv1d);

print "a\t$a\t$rv1a\t\$$rv2a<br>\n";
print "b\t$b\t$rv1b\t\$$rv2b<br>\n";
print "c\t$c\t$rv1c\t\$$rv2c<br>\n";
print "mc\t$mc\t$rv1mc\t\$$rv2mc<br>\n";
print "d\t$d\t$rv1d\t\$$rv2d<br>\n";

print "<br><p>name:\t$name<br>\n";
print "<br><p>id:\t$id<br>\n";

my $output = `C:\\ApacheAndPerl\\Apache2\\perl\\printenv_segment.pl`;
print "$output<br><br><br><br>";
$output = `dir`;
print '<PRE>';
print "$output<br>";
print '</PRE>';
print '</BODY></HTML>';

sub commify {
my $value = reverse $_[0];
$value =~ s/(\d\d\d)(?=\d)(?!\d*\.)/$1,/g;
return scalar reverse $value;
}
=========portfolio_construction.pl===================

#!c:/perl/bin/perl.exe
use strict;
use CGI qw/:standard/;
my $name = param('name');
my $id = param('id');

print header,
start_html('Portfolio history construction'),
h1("Hello $name"),
p("id = $id");
print p("This may take a few minutes.");
print end_html;

my $output = `"C:\\yohan\\PRODUCTION\\MakeNewPortfoliosETF\
\TedsMakeNewPortfolios.pl $id"`;
 
B

Ben Morrow

Quoth Ted Byers said:
Using the latest IndigoPerl, I have two scripts that do not behave
alike. Both are in the perl-bin directory of the Apache server
distributed with IndigoPerl.

The first one appended below works fine. It shows the output from a
perl script located in a directory tree completely outside the
directory tree for IndigoPerl, as well as a system command (this is
Windows XP). I get the expected output by providing the URL "http://
localhost/perl-bin/format_test.pl" to the browser.

The second one just hangs, displaying the initial text, but the script
appears to stop at the point where TedsMakeNewPortfolios.pl is
invoked. it is as if an attempt is made to run my scrpt, and control
is never returned to the main script. Yes, an association between
perl and the 'pl' extension has been created, and if I invoke
TedsMakeNewPortfolios.pl from the commandline (e.g. using
"TedsMakeNewPortfolios.pl 522"), it works flawlessly. So why isn't my
TedsMakeNewPortfolios.pl being executed?

I would avoid invoking perl scripts like this. There are often issues
with command-line parameters: the windows association mechanism seems to
be rather flaky in this respect. Either invoke it as

`perl c:\\...\\TedsMakeNewPortfolios.pl 522`

or as

`$^X c:\\...\\TedsMakeNewPortfolios.pl 522`

if perl isn't in your PATH, or, better, simply call the script using
'do'.
my $output = `"C:\\yohan\\PRODUCTION\\MakeNewPortfoliosETF\
\TedsMakeNewPortfolios.pl $id"`;

This is wrong. `` passes its contents to cmd /c, which handles any
further quoting itself. So effectively you are invoking

"C:\\yohan\\...\\TedsMakeNewPortfolios.pl 522"

What happens if you type this (*including* the quotes) at the command
line?

Ben
 
T

Ted Byers

Thanks Ben,

That was helpful.

Quoth Ted Byers <[email protected]>:






I would avoid invoking perl scripts like this. There are often issues
with command-line parameters: the windows association mechanism seems to
be rather flaky in this respect. Either invoke it as

    `perl c:\\...\\TedsMakeNewPortfolios.pl 522`

or as

    `$^X c:\\...\\TedsMakeNewPortfolios.pl 522`

if perl isn't in your PATH, or, better, simply call the script using
'do'.

Well, we're making progress. Before, none of the work that
TedsMakeNewPortfolios.pl handles was done. Now at least the data it
is supposed to produce is produced. I replaced my call with

`perl c:\\...\\TedsMakeNewPortfolios.pl $id`

Thanks. Now, I know what I need to do to finally fix this. You see,
the LAST thing that TedsMakeNewPortfolios.pl does is start an exe file
a colleague created, and IT starts another perl script that loads the
output data into a database (the language HE used does not have
support/drivers for accessing RDBMS - something that will change this
week). And THAT script is not getting executed.

The example for do in the documentation uses:

do 'stat.pl';

Will it handle command line arguments also. E.g.

do 'myscript.pl $argv[1]';

This is wrong. `` passes its contents to cmd /c, which handles any
further quoting itself. So effectively you are invoking

    "C:\\yohan\\...\\TedsMakeNewPortfolios.pl 522"

What happens if you type this (*including* the quotes) at the command
line?

This dies with a complain that it isn't recognized as a command,
program or batch file. That makes sense, now that I know the double
quotes would be passed on to cmd.
Ben

--
Heracles: Vulture! Here's a titbit for you / A few dried molecules of thegall
   From the liver of a friend of yours. / Excuse the arrow but I haveno spoon.
(Ted Hughes,        [ Heracles shoots Vulture with arrow. Vulturebursts into ]
 'Alcestis')        [ flame, and falls out of sight. ]         (e-mail address removed)

Thanks again

Ted
 
B

Ben Morrow

Quoth Ted Byers said:
Well, we're making progress. Before, none of the work that
TedsMakeNewPortfolios.pl handles was done. Now at least the data it
is supposed to produce is produced. I replaced my call with

`perl c:\\...\\TedsMakeNewPortfolios.pl $id`

Thanks. Now, I know what I need to do to finally fix this. You see,
the LAST thing that TedsMakeNewPortfolios.pl does is start an exe file
a colleague created, and IT starts another perl script that loads the
output data into a database (the language HE used does not have
support/drivers for accessing RDBMS - something that will change this
week). And THAT script is not getting executed.

Wow! I would want to see if you can avoid such a convoluted system of
invocations. At the very least, Perl scripts invoking Perl scripts can
be avoided.
The example for do in the documentation uses:

do 'stat.pl';

Will it handle command line arguments also. E.g.

do 'myscript.pl $argv[1]';

No. You can emulate it like

{
local @ARGV = ($id);
do 'script.pl';
}

but it would be better to rewrite the script to be used like this.
Ideally you would convert it into a .pm module you can 'use', which
exports a function that does all the real work; a half-way step would be
to wrap all the work in a function and then load the file with 'require'
or 'do'.

Ben
 
S

smallpond

do 'myscript.pl $argv[1]';

Only works if myscript.pl is in the current working directory.
Make sure that you either do chdir or give the full path to your
script.

--S
 
T

Ted Byers

Thanks Ben

Quoth Ted Byers <[email protected]>:







Wow! I would want to see if you can avoid such a convoluted system of
invocations. At the very least, Perl scripts invoking Perl scripts can
be avoided.
The perl invoking perl is a short term consequence of the real problem
we had to solve. We do some heavy duty number crunching, and this
crunching was much too slow to do either within our RDBMS or within
the Java based user interface(servlets + JSF). This is where the
compiled programs came in. We'll get the best performance when I get
time to implement some high performance C++ code, and this would
eliminate all need to the perl to handle data at all (since the C++
program would get input data from, and put output data to, the RDBMS
directly) and perl would then be just the glue that gets the right
program executed on demand, but there's no time for that yet. Anyway,
we needed a way to invoke these programs on demand from our web
interface. CGI on Tomcat wouldn't do it, and neither would our JSF
pages. As time allows, I will be cleaning up and simplifying the
system of invocations, but the boss wants to see it in action RSN.
The example for do in the documentation uses:
    do 'stat.pl';
Will it handle command line arguments also.  E.g.
do 'myscript.pl $argv[1]';

No. You can emulate it like

    {
        local @ARGV = ($id);
        do 'script.pl';
    }

but it would be better to rewrite the script to be used like this.
Ideally you would convert it into a .pm module you can 'use', which
exports a function that does all the real work; a half-way step would be
to wrap all the work in a function and then load the file with 'require'
or 'do'.

Thanks. Good to know.

Ted
 
C

C.DeRykus

do 'myscript.pl $argv[1]';

Only works if myscript.pl is in the current working directory.
Make sure that you either do chdir or give the full path to your
script.

Also, there are other cautionary notes about 'do'
so you may want to look closely at 'perldoc -f do'.
Careful error checking for instance looks at both
$! and $@. Reframing the code as a module and
then pulling in via 'use' or 'require' is usually
preferable.
 
B

Ben Morrow

Quoth Ted Byers said:
The perl invoking perl is a short term consequence of the real problem
we had to solve. We do some heavy duty number crunching, and this
crunching was much too slow to do either within our RDBMS or within
the Java based user interface(servlets + JSF). This is where the
compiled programs came in. We'll get the best performance when I get
time to implement some high performance C++ code, and this would
eliminate all need to the perl to handle data at all (since the C++
program would get input data from, and put output data to, the RDBMS
directly) and perl would then be just the glue that gets the right
program executed on demand, but there's no time for that yet.

Depending on how well you know Perl, it may be easier to use Perl with
Inline::C (or Inline::CPP, if that's your poison) to do the heavy
lifting. Of course, depending on what you're doing, there may already be
a Perl module that will do it for you: there are a lot of high-
performance numbercrunching modules on CPAN, and PDL is a generic fast
maths module. Of course, if you know C++ and your database's C++
bindings well, it may be best to stick with that.
Anyway,
we needed a way to invoke these programs on demand from our web
interface. CGI on Tomcat wouldn't do it, and neither would our JSF
pages. As time allows, I will be cleaning up and simplifying the
system of invocations, but the boss wants to see it in action RSN.

Heh. I'm sure you realise it's well worth insisting it gets cleaned up
Now, as otherwise it gets put off forever... :)

Ben
 
T

Ted Byers

do 'myscript.pl $argv[1]';
Only works if myscript.pl is in the current working directory.
Make sure that you either do chdir or give the full path to your
script.

Also, there are other cautionary notes about 'do'
so you may want to look closely at 'perldoc -f do'.
Careful error checking for instance looks at both
$! and $@.  Reframing the code as a module and
then pulling in via 'use' or 'require' is usually
preferable.

Thanks guys.

In this instance, by the time I am finished, there will be only one
perl script that a) invokes a compiled program with one commandline
argument and b) writes a web page to standard out, so the user of the
web application knows it is done. Both the perl and the compiled code
will be rewritten to make a smoother, faster, process.

So my calls, shown in my previous post, will end up being a call to a
compiled program I'll write in C++ and will be simpler than it is
right now. In this case, writing a module may not be warranted.

Cheers,

Ted
 
T

Ted Byers

Quoth Ted Byers <[email protected]>:





Depending on how well you know Perl, it may be easier to use Perl with
Inline::C (or Inline::CPP, if that's your poison) to do the heavy
lifting. Of course, depending on what you're doing, there may already be
a Perl module that will do it for you: there are a lot of high-
performance numbercrunching modules on CPAN, and PDL is a generic fast
maths module. Of course, if you know C++ and your database's C++
bindings well, it may be best to stick with that.
My perl is improving quickly, but I have substantially more experience
with high performance C++. So yes, I'll probably stick with the C++
and its bindings to my RDBMS.

I am looking to improve my C++ further by adapting my code to use
Intel's Thread Building Blocks library. I know there are FORTRAN and C
++ bindings for it (t was written in C++ in fact, using a lot of
advanced C++ idioms - definitely NOT for the C++ novice), and I know
FORTRAN even better than I know C++, having started with it a dozen
years before C++ was first released. It won't be nearly as quick as a
vector super computer, but it will consume all the power available
from a multicore processor, or a multitude of such processors if you
have the budget. Do you know if there are Perl bindings for this new
library? There is an open source version of it, if anyone is
interested.
Heh. I'm sure you realise it's well worth insisting it gets cleaned up
Now, as otherwise it gets put off forever... :)

Yup. But I have had employers that insisted I NOT waste time on
documentation! So I have my ways of coping (such as including cleanup/
refactoring efforts in other tasks that have been approved, or putting
documentation within my code as I'm writing it so the poor guy that
has to maintain it doesn't have to be an expert on advanced C++ design
patterns to figure out why I wrote my code as I did).

Cheers

Ted
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,995
Messages
2,570,230
Members
46,817
Latest member
DicWeils

Latest Threads

Top