[29731] in Perl-Users-Digest
Perl-Users Digest, Issue: 975 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Oct 25 21:14:19 2007
Date: Thu, 25 Oct 2007 18:14:10 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 25 Oct 2007 Volume: 11 Number: 975
Today's topics:
Re: PID of exec <peter@makholm.net>
Re: PID of exec hendedav@gmail.com
Re: PID of exec hendedav@gmail.com
Re: PID of exec <glennj@ncf.ca>
Re: PID of exec hendedav@gmail.com
Re: PID of exec (Gary E. Ansok)
Re: PID of exec <glennj@ncf.ca>
Re: PID of exec hendedav@gmail.com
Re: PID of exec <simon.chao@gmail.com>
Re: PID of exec hendedav@gmail.com
Re: PID of exec (Gary E. Ansok)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 25 Oct 2007 18:15:23 +0000
From: Peter Makholm <peter@makholm.net>
Subject: Re: PID of exec
Message-Id: <87hckfjc1w.fsf@hacking.dk>
hendedav@gmail.com writes:
> I switched the two lines of code as suggested, and I did get a print
> out, but it contained the same PID as the "my $pid=fork" statment.
> Here is the output:
Yes, of course. I wasn't actually reading what you wrote, just
noticed that you tried to write the pid out after the exec. 'use
warnings' should have warned you about that.
But ok, another (and better educated) guess about you problem:
'perldoc -f exec' says:
If there is more than one argument in LIST, or if LIST is an
array with more than one value, calls execvp(3) with the argu-
ments in LIST. If there is only one scalar argument or an
array with one element in it, the argument is checked for shell
metacharacters, and if there are any, the entire argument is
passed to the system's command shell for parsing (this is
"/bin/sh -c" on Unix platforms, but varies on other platforms).
If there are no shell metacharacters in the argument, it is
split into words and passed directly to "execvp", which is more
efficient. Examples:
exec('test.sh &') contains a shell metacharacter, namely '&', so what
exactly happens is
exec('/bin/sh', '-c', 'test.sh &');
You process (6498) executes /bin/sh which tries to run test.sh in the
background and then exists. Running in the background means forking
another process.
The solution is not to pass the argument to the system shell:
exec('test.sh');
And you're allready (kind of) running the process in the background
after you have fork'ed.
//Makholm
------------------------------
Date: Thu, 25 Oct 2007 11:32:57 -0700
From: hendedav@gmail.com
Subject: Re: PID of exec
Message-Id: <1193337177.852585.294020@d55g2000hsg.googlegroups.com>
On Oct 25, 2:15 pm, Peter Makholm <pe...@makholm.net> wrote:
> hende...@gmail.com writes:
> > I switched the two lines of code as suggested, and I did get a print
> > out, but it contained the same PID as the "my $pid=fork" statment.
> > Here is the output:
>
> Yes, of course. I wasn't actually reading what you wrote, just
> noticed that you tried to write the pid out after the exec. 'use
> warnings' should have warned you about that.
>
> But ok, another (and better educated) guess about you problem:
>
> 'perldoc -f exec' says:
>
> If there is more than one argument in LIST, or if LIST is an
> array with more than one value, calls execvp(3) with the argu-
> ments in LIST. If there is only one scalar argument or an
> array with one element in it, the argument is checked for shell
> metacharacters, and if there are any, the entire argument is
> passed to the system's command shell for parsing (this is
> "/bin/sh -c" on Unix platforms, but varies on other platforms).
> If there are no shell metacharacters in the argument, it is
> split into words and passed directly to "execvp", which is more
> efficient. Examples:
>
> exec('test.sh &') contains a shell metacharacter, namely '&', so what
> exactly happens is
>
> exec('/bin/sh', '-c', 'test.sh &');
>
> You process (6498) executes /bin/sh which tries to run test.sh in the
> background and then exists. Running in the background means forking
> another process.
>
> The solution is not to pass the argument to the system shell:
>
> exec('test.sh');
>
> And you're allready (kind of) running the process in the background
> after you have fork'ed.
>
> //Makholm
That makes sense. I have changed the code in the perl script and it
returns the correct pid!!! I read another post that said after
running the exec statment, it is a highly recommended to use an
"exit();" statement. Does this sound correct?
------------------------------
Date: Thu, 25 Oct 2007 12:16:59 -0700
From: hendedav@gmail.com
Subject: Re: PID of exec
Message-Id: <1193339819.852571.3670@v3g2000hsg.googlegroups.com>
On Oct 25, 2:32 pm, hende...@gmail.com wrote:
> On Oct 25, 2:15 pm, Peter Makholm <pe...@makholm.net> wrote:
>
>
>
> > hende...@gmail.com writes:
> > > I switched the two lines of code as suggested, and I did get a print
> > > out, but it contained the same PID as the "my $pid=fork" statment.
> > > Here is the output:
>
> > Yes, of course. I wasn't actually reading what you wrote, just
> > noticed that you tried to write the pid out after the exec. 'use
> > warnings' should have warned you about that.
>
> > But ok, another (and better educated) guess about you problem:
>
> > 'perldoc -f exec' says:
>
> > If there is more than one argument in LIST, or if LIST is an
> > array with more than one value, calls execvp(3) with the argu-
> > ments in LIST. If there is only one scalar argument or an
> > array with one element in it, the argument is checked for shell
> > metacharacters, and if there are any, the entire argument is
> > passed to the system's command shell for parsing (this is
> > "/bin/sh -c" on Unix platforms, but varies on other platforms).
> > If there are no shell metacharacters in the argument, it is
> > split into words and passed directly to "execvp", which is more
> > efficient. Examples:
>
> > exec('test.sh &') contains a shell metacharacter, namely '&', so what
> > exactly happens is
>
> > exec('/bin/sh', '-c', 'test.sh &');
>
> > You process (6498) executes /bin/sh which tries to run test.sh in the
> > background and then exists. Running in the background means forking
> > another process.
>
> > The solution is not to pass the argument to the system shell:
>
> > exec('test.sh');
>
> > And you're allready (kind of) running the process in the background
> > after you have fork'ed.
>
> > //Makholm
>
> That makes sense. I have changed the code in the perl script and it
> returns the correct pid!!! I read another post that said after
> running the exec statment, it is a highly recommended to use an
> "exit();" statement. Does this sound correct?
I have run into another problem. This code has been modified
(slightly) and inserted into a cgi script
if (defined (my $pid = fork)) {
if ($pid) {
local $SIG{CHLD} = "IGNORE";
print "Content-type: text/xml\n\n\n";
print "<info pid=\"". $pid ."\" date=\"".
scalar(localtime) ."\" />";
} else {
exec("/tmp/test.sh");
exit();
}
} else {
print "Content-type: text/xml\n\n\n";
print "<error>\n";
print "<message>The script couldn't be started.</message>\n";
print "</error>\n";
}
Now the webbrowser will not get a reply until the test.sh script has
finished executing. Any ideas?
Dave
------------------------------
Date: 25 Oct 2007 19:22:08 GMT
From: Glenn Jackman <glennj@ncf.ca>
Subject: Re: PID of exec
Message-Id: <slrnfi1r71.3ot.glennj@smeagol.ncf.ca>
At 2007-10-25 03:16PM, "hendedav@gmail.com" wrote:
[...]
> Now the webbrowser will not get a reply until the test.sh script has
> finished executing. Any ideas?
Your test.sh script should emit non-parsed headers:
http://www.oreilly.com/openbook/cgi/ch03_08.html
which means your perl script should probably be named "nph-whatever.pl"
(depending on your web server).
This is now off-topic for this group.
--
Glenn Jackman
"You can only be young once. But you can always be immature." -- Dave Barry
------------------------------
Date: Thu, 25 Oct 2007 12:59:39 -0700
From: hendedav@gmail.com
Subject: Re: PID of exec
Message-Id: <1193342379.234433.147500@v3g2000hsg.googlegroups.com>
On Oct 25, 3:22 pm, Glenn Jackman <gle...@ncf.ca> wrote:
> At 2007-10-25 03:16PM, "hende...@gmail.com" wrote:
> [...]
>
> > Now the webbrowser will not get a reply until the test.sh script has
> > finished executing. Any ideas?
>
> Your test.sh script should emit non-parsed headers:
> http://www.oreilly.com/openbook/cgi/ch03_08.html
>
> which means your perl script should probably be named "nph-whatever.pl"
> (depending on your web server).
>
> This is now off-topic for this group.
>
> --
> Glenn Jackman
> "You can only be young once. But you can always be immature." -- Dave Barry
I renamed the script and implemented the header suggested on that
link, but it still is not working. Can you suggest a group to post in
for this problem?
Thanks,
Dave
------------------------------
Date: Thu, 25 Oct 2007 20:12:15 +0000 (UTC)
From: ansok@alumni.caltech.edu (Gary E. Ansok)
Subject: Re: PID of exec
Message-Id: <ffqtav$93s$1@naig.caltech.edu>
In article <1193339819.852571.3670@v3g2000hsg.googlegroups.com>,
<hendedav@gmail.com> wrote:
>I have run into another problem. This code has been modified
>(slightly) and inserted into a cgi script
>
>if (defined (my $pid = fork)) {
> if ($pid) {
> local $SIG{CHLD} = "IGNORE";
> print "Content-type: text/xml\n\n\n";
> print "<info pid=\"". $pid ."\" date=\"".
>scalar(localtime) ."\" />";
> } else {
> exec("/tmp/test.sh");
> exit();
> }
>} else {
> print "Content-type: text/xml\n\n\n";
> print "<error>\n";
> print "<message>The script couldn't be started.</message>\n";
> print "</error>\n";
>}
>
>Now the webbrowser will not get a reply until the test.sh script has
>finished executing. Any ideas?
One possibility is that the server is waiting for the output to be
completed before sending it off to the browser. The server won't
see end-of-file on the read end of the internal connection (between
the server and the cgi script) until all the processes have closed
the write end.
In this case, the process running /tmp/test.sh still has its standard
output set to that connection, so the server still needs to wait in
case test.sh writes more data.
The solution is to redirect standard output to a more suitable place
(or discard it by using /dev/null):
> } else {
open STDOUT, '>', '/dev/null';
> exec("/tmp/test.sh");
> exit();
> }
(Normally, we'd check to see if the open succeeded, but in this case
we presumably don't care as long as the existing channel gets closed.)
I would also close or re-direct STDIN and STDERR, unless you have
a reason not to.
Gary
--
The recipe says "toss lightly," but I suppose that depends
on how much you eat and how bad the cramps get. - J. Lileks
------------------------------
Date: 25 Oct 2007 20:25:58 GMT
From: Glenn Jackman <glennj@ncf.ca>
Subject: Re: PID of exec
Message-Id: <slrnfi1uun.3ot.glennj@smeagol.ncf.ca>
At 2007-10-25 03:59PM, "hendedav@gmail.com" wrote:
> On Oct 25, 3:22 pm, Glenn Jackman <gle...@ncf.ca> wrote:
> > At 2007-10-25 03:16PM, "hende...@gmail.com" wrote:
> > [...]
> >
> > > Now the webbrowser will not get a reply until the test.sh script has
> > > finished executing. Any ideas?
> >
> > Your test.sh script should emit non-parsed headers:
> > http://www.oreilly.com/openbook/cgi/ch03_08.html
> >
> > which means your perl script should probably be named "nph-whatever.pl"
> > (depending on your web server).
> >
> > This is now off-topic for this group.
>
> I renamed the script and implemented the header suggested on that
> link, but it still is not working. Can you suggest a group to post in
> for this problem?
I'd say comp.infosystems.www.authoring.cgi but it's defunct. There's
perl.beginners.cgi where I found this reference:
http://www.stonehenge.com/merlyn/LinuxMag/col39.html
--
Glenn Jackman
"You can only be young once. But you can always be immature." -- Dave Barry
------------------------------
Date: Thu, 25 Oct 2007 13:40:34 -0700
From: hendedav@gmail.com
Subject: Re: PID of exec
Message-Id: <1193344834.040283.130360@50g2000hsm.googlegroups.com>
On Oct 25, 4:12 pm, an...@alumni.caltech.edu (Gary E. Ansok) wrote:
> In article <1193339819.852571.3...@v3g2000hsg.googlegroups.com>,
>
>
>
> <hende...@gmail.com> wrote:
> >I have run into another problem. This code has been modified
> >(slightly) and inserted into a cgi script
>
> >if (defined (my $pid = fork)) {
> > if ($pid) {
> > local $SIG{CHLD} = "IGNORE";
> > print "Content-type: text/xml\n\n\n";
> > print "<info pid=\"". $pid ."\" date=\"".
> >scalar(localtime) ."\" />";
> > } else {
> > exec("/tmp/test.sh");
> > exit();
> > }
> >} else {
> > print "Content-type: text/xml\n\n\n";
> > print "<error>\n";
> > print "<message>The script couldn't be started.</message>\n";
> > print "</error>\n";
> >}
>
> >Now the webbrowser will not get a reply until the test.sh script has
> >finished executing. Any ideas?
>
> One possibility is that the server is waiting for the output to be
> completed before sending it off to the browser. The server won't
> see end-of-file on the read end of the internal connection (between
> the server and the cgi script) until all the processes have closed
> the write end.
>
> In this case, the process running /tmp/test.sh still has its standard
> output set to that connection, so the server still needs to wait in
> case test.sh writes more data.
>
> The solution is to redirect standard output to a more suitable place
> (or discard it by using /dev/null):
>
> > } else {
>
> open STDOUT, '>', '/dev/null';
>
> > exec("/tmp/test.sh");
> > exit();
> > }
>
> (Normally, we'd check to see if the open succeeded, but in this case
> we presumably don't care as long as the existing channel gets closed.)
>
> I would also close or re-direct STDIN and STDERR, unless you have
> a reason not to.
>
> Gary
> --
> The recipe says "toss lightly," but I suppose that depends
> on how much you eat and how bad the cramps get. - J. Lileks
Thanks for the help Gary. I inserted the redirect for STDOUT and also
tried STDIN (not sure how to with STDERR if the arrows are any
indication). I have also tried in on the commandline. here is what I
have tried:
} else {
open STDOUT, '>', '/dev/null';
open STDIN, '<', '/dev/null';
#open STDERR, '?', '/dev/null';
exec("/tmp/test.sh </dev/null >>/dev/null 2>&1");
}
Still no luck. Any other ideas or corrections in the code to try?
Dave
------------------------------
Date: Thu, 25 Oct 2007 22:09:52 -0000
From: nolo contendere <simon.chao@gmail.com>
Subject: Re: PID of exec
Message-Id: <1193350192.407708.118830@50g2000hsm.googlegroups.com>
On Oct 25, 4:40 pm, hende...@gmail.com wrote:
> On Oct 25, 4:12 pm, an...@alumni.caltech.edu (Gary E. Ansok) wrote:
>
>
>
> > In article <1193339819.852571.3...@v3g2000hsg.googlegroups.com>,
>
> > <hende...@gmail.com> wrote:
> > >I have run into another problem. This code has been modified
> > >(slightly) and inserted into a cgi script
>
> > >if (defined (my $pid = fork)) {
> > > if ($pid) {
> > > local $SIG{CHLD} = "IGNORE";
> > > print "Content-type: text/xml\n\n\n";
> > > print "<info pid=\"". $pid ."\" date=\"".
> > >scalar(localtime) ."\" />";
> > > } else {
> > > exec("/tmp/test.sh");
> > > exit();
> > > }
> > >} else {
> > > print "Content-type: text/xml\n\n\n";
> > > print "<error>\n";
> > > print "<message>The script couldn't be started.</message>\n";
> > > print "</error>\n";
> > >}
>
> > >Now the webbrowser will not get a reply until the test.sh script has
> > >finished executing. Any ideas?
>
> > One possibility is that the server is waiting for the output to be
> > completed before sending it off to the browser. The server won't
> > see end-of-file on the read end of the internal connection (between
> > the server and the cgi script) until all the processes have closed
> > the write end.
>
> > In this case, the process running /tmp/test.sh still has its standard
> > output set to that connection, so the server still needs to wait in
> > case test.sh writes more data.
>
> > The solution is to redirect standard output to a more suitable place
> > (or discard it by using /dev/null):
>
> > > } else {
>
> > open STDOUT, '>', '/dev/null';
>
> > > exec("/tmp/test.sh");
> > > exit();
> > > }
>
> > (Normally, we'd check to see if the open succeeded, but in this case
> > we presumably don't care as long as the existing channel gets closed.)
>
> > I would also close or re-direct STDIN and STDERR, unless you have
> > a reason not to.
>
> > Gary
> > --
> > The recipe says "toss lightly," but I suppose that depends
> > on how much you eat and how bad the cramps get. - J. Lileks
>
> Thanks for the help Gary. I inserted the redirect for STDOUT and also
> tried STDIN (not sure how to with STDERR if the arrows are any
> indication). I have also tried in on the commandline. here is what I
> have tried:
>
> } else {
>
> open STDOUT, '>', '/dev/null';
> open STDIN, '<', '/dev/null';
> #open STDERR, '?', '/dev/null';
> exec("/tmp/test.sh </dev/null >>/dev/null 2>&1");
>
> }
>
> Still no luck. Any other ideas or corrections in the code to try?
>
> Dave
maybe autoflush?
$|++;
------------------------------
Date: Thu, 25 Oct 2007 15:47:19 -0700
From: hendedav@gmail.com
Subject: Re: PID of exec
Message-Id: <1193352439.621195.249620@22g2000hsm.googlegroups.com>
On Oct 25, 6:09 pm, nolo contendere <simon.c...@gmail.com> wrote:
> On Oct 25, 4:40 pm, hende...@gmail.com wrote:
>
>
>
> > On Oct 25, 4:12 pm, an...@alumni.caltech.edu (Gary E. Ansok) wrote:
>
> > > In article <1193339819.852571.3...@v3g2000hsg.googlegroups.com>,
>
> > > <hende...@gmail.com> wrote:
> > > >I have run into another problem. This code has been modified
> > > >(slightly) and inserted into a cgi script
>
> > > >if (defined (my $pid = fork)) {
> > > > if ($pid) {
> > > > local $SIG{CHLD} = "IGNORE";
> > > > print "Content-type: text/xml\n\n\n";
> > > > print "<info pid=\"". $pid ."\" date=\"".
> > > >scalar(localtime) ."\" />";
> > > > } else {
> > > > exec("/tmp/test.sh");
> > > > exit();
> > > > }
> > > >} else {
> > > > print "Content-type: text/xml\n\n\n";
> > > > print "<error>\n";
> > > > print "<message>The script couldn't be started.</message>\n";
> > > > print "</error>\n";
> > > >}
>
> > > >Now the webbrowser will not get a reply until the test.sh script has
> > > >finished executing. Any ideas?
>
> > > One possibility is that the server is waiting for the output to be
> > > completed before sending it off to the browser. The server won't
> > > see end-of-file on the read end of the internal connection (between
> > > the server and the cgi script) until all the processes have closed
> > > the write end.
>
> > > In this case, the process running /tmp/test.sh still has its standard
> > > output set to that connection, so the server still needs to wait in
> > > case test.sh writes more data.
>
> > > The solution is to redirect standard output to a more suitable place
> > > (or discard it by using /dev/null):
>
> > > > } else {
>
> > > open STDOUT, '>', '/dev/null';
>
> > > > exec("/tmp/test.sh");
> > > > exit();
> > > > }
>
> > > (Normally, we'd check to see if the open succeeded, but in this case
> > > we presumably don't care as long as the existing channel gets closed.)
>
> > > I would also close or re-direct STDIN and STDERR, unless you have
> > > a reason not to.
>
> > > Gary
> > > --
> > > The recipe says "toss lightly," but I suppose that depends
> > > on how much you eat and how bad the cramps get. - J. Lileks
>
> > Thanks for the help Gary. I inserted the redirect for STDOUT and also
> > tried STDIN (not sure how to with STDERR if the arrows are any
> > indication). I have also tried in on the commandline. here is what I
> > have tried:
>
> > } else {
>
> > open STDOUT, '>', '/dev/null';
> > open STDIN, '<', '/dev/null';
> > #open STDERR, '?', '/dev/null';
> > exec("/tmp/test.sh </dev/null >>/dev/null 2>&1");
>
> > }
>
> > Still no luck. Any other ideas or corrections in the code to try?
>
> > Dave
>
> maybe autoflush?
> $|++;
That seemed to have worked. Here is the adjusted code:
} else {
$|++;
open STDOUT, '>', '/dev/null';
open STDIN, '>', '/dev/null';
open STDERR, '>', '/dev/null';
exec("/tmp/test.sh");
exit();
}
Does this look okay or do I need to add anything else?
Thanks,
Dave
------------------------------
Date: Thu, 25 Oct 2007 23:49:53 +0000 (UTC)
From: ansok@alumni.caltech.edu (Gary E. Ansok)
Subject: Re: PID of exec
Message-Id: <ffra31$d2h$1@naig.caltech.edu>
In article <1193352439.621195.249620@22g2000hsm.googlegroups.com>,
<hendedav@gmail.com> wrote:
[much snippage]
>That seemed to have worked. Here is the adjusted code:
>
>} else {
> $|++;
> open STDOUT, '>', '/dev/null';
> open STDIN, '>', '/dev/null';
> open STDERR, '>', '/dev/null';
> exec("/tmp/test.sh");
> exit();
>}
STDIN should be opened with '<' rather than '>'. This won't matter
unless /tmp/test.sh or something it calls tries to read from standard
input, but if it does, better to get end-of-file instead of a
runtime error.
Gar
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 975
**************************************
