[29969] in Perl-Users-Digest
Perl-Users Digest, Issue: 1212 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jan 18 14:14:25 2008
Date: Fri, 18 Jan 2008 11:14:11 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 18 Jan 2008 Volume: 11 Number: 1212
Today's topics:
pop up to capture user and password burrell.john@yahoo.com
Re: pop up to capture user and password <zen13097@zen.co.uk>
Re: pop up to capture user and password burrell.john@yahoo.com
Re: pop up to capture user and password <glex_no-spam@qwest-spam-no.invalid>
Re: pop up to capture user and password burrell.john@yahoo.com
sprintf rouding error Broki@gmx.de
Re: sprintf rouding error Broki@gmx.de
Re: sprintf rouding error <ben@morrow.me.uk>
Re: sprintf rouding error <jurgenex@hotmail.com>
Re: sprintf rouding error <hjp-usenet2@hjp.at>
Re: Wait for background processes to complete <hjp-usenet2@hjp.at>
Re: Wait for background processes to complete <hjp-usenet2@hjp.at>
Re: Wait for background processes to complete <ced@blv-sam-01.ca.boeing.com>
Re: Wait for background processes to complete <pgodfrin@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 18 Jan 2008 05:12:07 -0800 (PST)
From: burrell.john@yahoo.com
Subject: pop up to capture user and password
Message-Id: <0f1d0e2f-ccca-4473-af6a-b7a68fa1f527@i7g2000prf.googlegroups.com>
Hello,
I am currently knee deep in a cgi program intended to query the user
for their username and password
and then logging in to an aplication with a http;/IP/login?
MyId=12345&username=bert&password=xxxx
Have successfully called from a program an URL IPadress/cgi-bin/
myprog.cgi?MyId=12345
myprog.cgi has been invoked and unwebified the input thus:
#!/usr/bin/perl
# Get the input
$buffer = $ENV{'QUERY_STRING'};
@pairs = split(/&/, $buffer);
foreach $pair (@pairs)
{
($name, $value) = split(/=/, $pair);
# Un-Webify plus signs and %-encoding
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$name =~ tr/+/ /;
$name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$FORM{$name} = $value;
}
So could someone please help me with what to do next?
It is rather urgent, in a fit of enthusiasm promised it for today
without having a proper knowledge...
TIA
J
------------------------------
Date: 18 Jan 2008 14:20:49 GMT
From: Dave Weaver <zen13097@zen.co.uk>
Subject: Re: pop up to capture user and password
Message-Id: <4790b5c1$0$21104$da0feed9@news.zen.co.uk>
burrell.john@yahoo.com <burrell.john@yahoo.com> wrote:
>
> #!/usr/bin/perl
> # Get the input
> $buffer = $ENV{'QUERY_STRING'};
> @pairs = split(/&/, $buffer);
> foreach $pair (@pairs)
> {
> ($name, $value) = split(/=/, $pair);
> # Un-Webify plus signs and %-encoding
> $value =~ tr/+/ /;
> $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
> $name =~ tr/+/ /;
> $name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
> $FORM{$name} = $value;
> }
Ick! Don't do that - it's not only ugly code but prone to errors.
Use the CGI module that comes with Perl.
Also, get used to using the 'strict' and 'warnings' pragmas - it
will make your code better.
#!/usr/bin/perl
use strict;
use warnings;
use CGI ':standard';
my $id = param( 'MyId' );
# ... etc
Type `perldoc CGI` for the details.
------------------------------
Date: Fri, 18 Jan 2008 09:14:14 -0800 (PST)
From: burrell.john@yahoo.com
Subject: Re: pop up to capture user and password
Message-Id: <f8c057f9-75d8-413a-95fa-8757f4ce17e6@e4g2000hsg.googlegroups.com>
On 18 Jan, 14:20, Dave Weaver <zen13...@zen.co.uk> wrote:
> burrell.j...@yahoo.com <burrell.j...@yahoo.com> wrote:
> Ick! Don't do that - it's not only ugly code but prone to errors.
> Use the CGI module that comes with Perl.
>
> Also, get used to using the 'strict' and =A0'warnings' pragmas - it
> will make your code better.
>
> =A0#!/usr/bin/perl
> =A0use strict;
> =A0use warnings;
> =A0use CGI ':standard';
>
> =A0my $id =3D param( 'MyId' );
> =A0# ... etc
>
> Type `perldoc CGI` for the details.- Hide quoted text -
Thanks - Good advice! Read the fine Perldoc!
Got a few lines of good code!
What I want to do now is MD5 hash the password and invoke another URL
in a new window passing in MyId, User and secret.
Can you please tell me the next step??
#!/usr/bin/perl
use strict;
use warnings;
use CGI ':standard';
my $MyId =3D param( 'MyId' );
print header,
start_html('Enter Logon Details'),
h1('Enter Logon Details'),
h1($LinkId),
start_form,
"What's your name? ",textfield('user'),p,
"What's your password? ",password_field('secret','',50,80);
submit,
end_form,
hr;
------------------------------
Date: Fri, 18 Jan 2008 11:26:26 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: pop up to capture user and password
Message-Id: <4790e143$0$3578$815e3792@news.qwest.net>
burrell.john@yahoo.com wrote:
[...]
> What I want to do now is MD5 hash the password and invoke another URL
> in a new window passing in MyId, User and secret.
> Can you please tell me the next step??
Actually, what you want to do now is some research. There are MD5
modules available (http://search.cpan.org/search?query=md5&mode=all)
and plenty of documentation, books, and articles on CGI. Use your
favorite Internet search engine to help find them and after you've
learned what to do and have specific questions or problems, then
post your code and your questions.
------------------------------
Date: Fri, 18 Jan 2008 10:20:51 -0800 (PST)
From: burrell.john@yahoo.com
Subject: Re: pop up to capture user and password
Message-Id: <798a5230-4ab7-4855-9df3-c64532de2e11@v4g2000hsf.googlegroups.com>
On 18 Jan, 17:26, "J. Gleixner" <glex_no-s...@qwest-spam-no.invalid>
wrote:
> burrell.j...@yahoo.com wrote:
>
> [...]
>
> > What I want to do now is MD5 hash the password and invoke another URL
> > in a new window passing in MyId, User and secret.
> > Can you please tell me the next step??
>
> Actually, what you want to do now is some research. =A0There are MD5
> modules available (http://search.cpan.org/search?query=3Dmd5&mode=3Dall)
> and plenty of documentation, books, and articles on CGI. =A0Use your
> favorite Internet search engine to help find them and after you've
> learned what to do and have specific questions or problems, then
> post your code and your questions.
Thanks for that! I now have the following code:
#!/usr/bin/perl
use strict;
use warnings;
use CGI ':standard';
use Digest::MD5 qw(md5_hex);
my $LinkId =3D param( 'MyId' );
print header,
start_html('Enter Louis Logon Details'),
h1('Enter Louis Logon Details`'),
h1($MyId),
start_form,
"What's your name? ",textfield('name'),p,
"What's your password? ",textfield('password'),p,
submit,
end_form,
hr;
Actually I think I need to pass the 3 values $MyId, $Name and
$password like so:
http://IP/cgi-bin/nextProg.cgi?MyId=3D123&Name=3Dfred&password=3Dsecret
So I need to work some magic with submit.
Mr Google seems silent on how to do this.
If you help me I will be a happy man - and so will my boss and a
number of other people...
------------------------------
Date: Fri, 18 Jan 2008 05:07:48 -0800 (PST)
From: Broki@gmx.de
Subject: sprintf rouding error
Message-Id: <55f16020-9bba-4c57-82a1-08fe1909bbd4@d21g2000prf.googlegroups.com>
Hello,
I could observe something strange under different versions of perl
[ActiveState 5.6,5.8] and CPUs[P4,CoreDuo].
(both under WIN XP SP2)
Example:
x=3D1.5;sprintf("%.0f",$x);->2 [ok]
BUT
$x=3D5830*1.15; ->the calculated 6704.5 gets rounded down to 6704 ![not
okay].
Is this a known problem?!
G=F6tz
------------------------------
Date: Fri, 18 Jan 2008 05:25:05 -0800 (PST)
From: Broki@gmx.de
Subject: Re: sprintf rouding error
Message-Id: <07d95475-30e3-4576-acba-b9fe35608ab9@v17g2000hsa.googlegroups.com>
On 18 Jan., 14:07, Br...@gmx.de wrote:
> Hello,
> I could observe something strange under different versions of perl
> [ActiveState 5.6,5.8] and CPUs[P4,CoreDuo].
> (both under WIN XP SP2)
>
> Example:
> x=3D1.5;sprintf("%.0f",$x);->2 [ok]
> BUT
> $x=3D5830*1.15; ->the calculated 6704.5 gets rounded down to 6704 ![not
> okay].
>
> Is this a known problem?!
>
> G=F6tz
I found the answer with google.
Perl uses an biased rounding function.
at .5 50%up - 50% down.
I am surprised.
Its an IEEE rule.
------------------------------
Date: Fri, 18 Jan 2008 13:38:18 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: sprintf rouding error
Message-Id: <anm665-vu6.ln1@osiris.mauzo.dyndns.org>
Quoth Broki@gmx.de:
>
> Example:
> x=1.5;sprintf("%.0f",$x);->2 [ok]
> BUT
> $x=5830*1.15; ->the calculated 6704.5 gets rounded down to 6704 ![not
> okay].
>
> Is this a known problem?!
Known, but not a problem. Perl's default float-to-string conversion uses
DBL_DIG (from your system's <float.h>) digits of precision, as this is
all that is guaranteed to be accurate. However, the number actually has
more precision than that, which can mean it rounds differently from the
way you would expect. On my system, DBL_DIG is 15, and I get
~% perl -le'print sprintf $_, 5830*1.15 for qw/%s %f %.0f %.20f/'
6704.5
6704.500000
6704
6704.49999999999909050530
so the value calculated is actually a smidge smaller than 6704.5, and so
rounds down.
Ben
------------------------------
Date: Fri, 18 Jan 2008 14:19:08 GMT
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: sprintf rouding error
Message-Id: <p0d1p3p6bsm543bodr2b3hr29u0pjtvqe7@4ax.com>
Broki@gmx.de wrote:
>On 18 Jan., 14:07, Br...@gmx.de wrote:
>> x=1.5;sprintf("%.0f",$x);->2 [ok]
>> BUT
>> $x=5830*1.15; ->the calculated 6704.5 gets rounded down to 6704 ![not
>> okay].
>
>I found the answer with google.
>Perl uses an biased rounding function.
>at .5 50%up - 50% down.
Actually no. Try printing your number with e.g. 40 digits:
printf '%.40f', $x;
and you will see that you fell for the oldest problem in computer numerics.
"Thou shalt not use floating point if thou expect exact results"
For a brief explanation why see "perldoc -q 999". For a comprehensive answer
see the introductory class in Computer Numerics at your favourite
university.
jue
------------------------------
Date: Fri, 18 Jan 2008 16:43:07 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: sprintf rouding error
Message-Id: <slrnfp1i8c.l12.hjp-usenet2@hrunkner.hjp.at>
On 2008-01-18 13:25, Broki@gmx.de <Broki@gmx.de> wrote:
> On 18 Jan., 14:07, Br...@gmx.de wrote:
>> I could observe something strange under different versions of perl
>> [ActiveState 5.6,5.8] and CPUs[P4,CoreDuo].
>> (both under WIN XP SP2)
>>
>> Example:
>> x=1.5;sprintf("%.0f",$x);->2 [ok]
>> BUT
>> $x=5830*1.15; ->the calculated 6704.5 gets rounded down to 6704 ![not
>> okay].
1.15 is not representable exactly in binary floating point (just like
1/3 isn't exactly representable in decimal floating point), so since you
don't multiply 5830 by exactly 1.15, the result won't be exactly 6704.5
- it will be slightly more or slightly less and this number will then be
rounded correctly. You get more accurate results if you avoid decimals:
5830*115/100 is exactly 6704.5.
Incidentally, the correct rounding of 6704.5 *is* 6704, so in this case
the result is what you should expect.
>> Is this a known problem?!
>
> I found the answer with google.
> Perl uses an biased rounding function.
You mean "non-biased" (unlike the rounding rule you learn in school
which is biased).
> at .5 50%up - 50% down.
Be careful here. ".5" in english-speaking countries means "0.5", so what
you wrote is wrong: 0.5 is always rounded down because 0 is even. I
guess you meant that half of the numbers n + 0.5 where n is an integer
get rounded up and half of them get rounded down. That's correct.
> I am surprised. Its an IEEE rule.
You should read the newsgroup you are posting to - this was discussed in
another thread only a few days ago.
hp
------------------------------
Date: Fri, 18 Jan 2008 16:11:14 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Wait for background processes to complete
Message-Id: <slrnfp1gcl.l12.hjp-usenet2@hrunkner.hjp.at>
On 2008-01-18 01:34, comp.llang.perl.moderated <ced@blv-sam-01.ca.boeing.com> wrote:
> On Jan 17, 3:12 pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
>> On 2008-01-17 00:52, comp.llang.perl.moderated <c...@blv-sam-01.ca.boeing.com> wrote:
>>
>> > On Jan 16, 2:29 pm, pgodfrin <pgodf...@gmail.com> wrote:
>> >> On Jan 16, 4:17 pm, xhos...@gmail.com wrote:
>> >> > ## On Linux, wait returns -1 when there are no living children to wait for.
>> >> > 1 until -1==wait();
>>
>> >> > > exit;
>>
>> >> Thanks Xho - I've removed the signal handler, but it seems wait always
>> >> returns -1 so - the loop is a nop? Where in the code should it go?
>>
>> > I'll pipe in here since the 'quick 'n dirty' solution
>> > was mangled and diss'ed.
>>
>> > The safest action is an asynchronous wait with a
>>
>> Before 5.8.0 that was actually unsafe. But while it is now safe in perl
>
> Huh.. just for clarity, here's what I wrote:
>
> use POSIX ":sys_wait_h";
> $SIG{CHLD} = \&REAPER;
> # now do something that forks...
> ...
> sub REAPER { 1 while waitpid(-1, WNOHANG)) > 0; }
>
> In fact, historically, there's a clear recommendation to tight-loop
> exactly as shown because you may lose signals occurring in
> near concurrency if you don't.
The problem with this approach is that until 5.8.0 (when "safe signals"
were introduced), the REAPER function would be called as soon as the
signal arrived regardless of what the perl interpreter was doing at the
time - there was a very real risk that this would crash the perl
interpreter (in a real world application which forked about 50,000 to
100,000 times a day, the parent process would crash every few days with
perl 5.6.0). In C the POSIX standard explicitely states which functions
are safe inside a signal handler (and the rest has to be considered
unsafe), but for perl no such list existed (so everything has to be
considered unsafe). In perl 5.8.0, the "real" signal handler only notes
that a signal arrived, and perl will than invoke sub REAPER when it can
safely do this (which may be quite some time later).
> Or are you suggesting that an explicit wait on each of the child
> processes would somehow be safer...
Avoiding signal handles was indeed "somehow safer" before 5.8.0,
because signal handlers were fundamentally unsafe (and arguably broken)
in perl.
But that was only a side note. My real argument was that this code has a
completely different purpose: It "reaps" children as soon as they exit
to avoid zombies. This is useful for long-running server processes which
don't really want to wait for their children - they just want to fire
them off and then forget about them. But the OP explicitely wants to
wait for his children so that is what he should do. There is no need for
any signal handlers - they just add complexity which isn't needed and
obscure the purpose of the code.
>> 5.8.x (and 5.10.x), it still has the tiny flaw of absolutely *not* doing
>> what the OP wants. Xho's solution is safe (and was so in all perl
>> versions and does what the OP wants. Well, almost - wait can return -1
>> if it is interrupted so one should check $! in addition to the return
>> value.
>>
> You're right, a asynchronous wait would need to
> save child pids and loop until they're reaped.
Yes. But why would you want to do that if it can be done a lot simpler
and more straightforward?
hp
------------------------------
Date: Fri, 18 Jan 2008 16:20:57 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Wait for background processes to complete
Message-Id: <slrnfp1gus.l12.hjp-usenet2@hrunkner.hjp.at>
On 2008-01-18 02:02, grocery_stocker <cdalten@gmail.com> wrote:
> On Jan 16, 9:37 pm, Ben Morrow <b...@morrow.me.uk> wrote:
>> The only thing that matters about %kids are its keys: we never use
>> the values, so they can be set to anything. I prefer using 1 since
>> then the values are all true; you can get slightly better memory use
>> with
>>
>> $kids{$pid} = ();
>>
>> which inserts the key but doesn't create a value for it at all, but
>> then you have to test with exists, which I find annoying. Since in
>> this case I don't test for existance of keys at all, this doesn't
>> matter: using 1 is just a habit.
>
> Okay, why would you have to test for exists if
>
> $kids{$pid} = ();
>
> just creates something like undef.
Consider:
#!/usr/bin/perl
use warnings;
use strict;
my %kids;
$kids{3} = ();
$kids{5} = ();
for (1 .. 9) {
print "$_\n" if is_kid($_);
}
sub is_kid {
return exists($kids{$_[0]});
}
__END__
3
5
Please find an implementation for sub is_kid which doesn't use exists.
hp
------------------------------
Date: Fri, 18 Jan 2008 09:30:22 -0800 (PST)
From: "comp.llang.perl.moderated" <ced@blv-sam-01.ca.boeing.com>
Subject: Re: Wait for background processes to complete
Message-Id: <48b8486f-a7bb-4eaa-ae0d-17d5996fa0e6@i7g2000prf.googlegroups.com>
On Jan 18, 7:11 am, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> On 2008-01-18 01:34, comp.llang.perl.moderated <c...@blv-sam-01.ca.boeing.com> wrote:
>
>
>
> > On Jan 17, 3:12 pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> >> On 2008-01-17 00:52, comp.llang.perl.moderated <c...@blv-sam-01.ca.boeing.com> wrote:
>
> >> > On Jan 16, 2:29 pm, pgodfrin <pgodf...@gmail.com> wrote:
> >> >> On Jan 16, 4:17 pm, xhos...@gmail.com wrote:
> >> >> > ## On Linux, wait returns -1 when there are no living children to wait for.
> >> >> > 1 until -1==wait();
>
> >> >> > > exit;
>
> >> >> Thanks Xho - I've removed the signal handler, but it seems wait always
> >> >> returns -1 so - the loop is a nop? Where in the code should it go?
>
> >> > I'll pipe in here since the 'quick 'n dirty' solution
> >> > was mangled and diss'ed.
>
> >> > The safest action is an asynchronous wait with a
>
> >> Before 5.8.0 that was actually unsafe. But while it is now safe in perl
>
> > Huh.. just for clarity, here's what I wrote:
>
> > use POSIX ":sys_wait_h";
> > $SIG{CHLD} = \&REAPER;
> > # now do something that forks...
> > ...
> > sub REAPER { 1 while waitpid(-1, WNOHANG)) > 0; }
>
> > In fact, historically, there's a clear recommendation to tight-loop
> > exactly as shown because you may lose signals occurring in
> > near concurrency if you don't.
>
> The problem with this approach is that until 5.8.0 (when "safe signals"
> were introduced), the REAPER function would be called as soon as the
> signal arrived regardless of what the perl interpreter was doing at the
> time - there was a very real risk that this would crash the perl
> interpreter (in a real world application which forked about 50,000 to
> 100,000 times a day, the parent process would crash every few days with
> perl 5.6.0). In C the POSIX standard explicitely states which functions
> are safe inside a signal handler (and the rest has to be considered
> unsafe), but for perl no such list existed (so everything has to be
> considered unsafe). In perl 5.8.0, the "real" signal handler only notes
> that a signal arrived, and perl will than invoke sub REAPER when it can
> safely do this (which may be quite some time later).
>
> > Or are you suggesting that an explicit wait on each of the child
> > processes would somehow be safer...
>
> Avoiding signal handles was indeed "somehow safer" before 5.8.0,
> because signal handlers were fundamentally unsafe (and arguably broken)
> in perl.
Hm, I thought I recalled that, even with
Perl's broken pre-5.8 signal handling, the
issue was most likely to surface with op's
not on POSIX's safe list. Something like
'waitpid', which is on POSIX's safe list,
in a simple loop was unlikely to cause a
problem.
>
> But that was only a side note. My real argument was that this code has a
> completely different purpose: It "reaps" children as soon as they exit
> to avoid zombies. This is useful for long-running server processes which
> don't really want to wait for their children - they just want to fire
> them off and then forget about them. But the OP explicitely wants to
> wait for his children so that is what he should do. There is no need for
> any signal handlers - they just add complexity which isn't needed and
> obscure the purpose of the code.
>
> >> 5.8.x (and 5.10.x), it still has the tiny flaw of absolutely *not* doing
> >> what the OP wants. Xho's solution is safe (and was so in all perl
> >> versions and does what the OP wants. Well, almost - wait can return -1
> >> if it is interrupted so one should check $! in addition to the return
> >> value.
>
> > You're right, a asynchronous wait would need to
> > save child pids and loop until they're reaped.
>
> Yes. But why would you want to do that if it can be done a lot simpler
> and more straightforward?
>
Yes I agree that's probably true here but, as you mention, you'd have
to check for -1 because the process was reaped, stopped, or terminated
by some signal for instance. And, if you're concerned about zombies,
you really need to keep a list of pids to wait on. To me the solutions
are very close modulo the signal function setup. Even outside the
daemon
setting, I like the signal solution which handles
the reaping as soon as it occurs and bundles child cleanup neatly in a
separate sub.
--
Charles DeRykus
------------------------------
Date: Fri, 18 Jan 2008 09:47:37 -0800 (PST)
From: pgodfrin <pgodfrin@gmail.com>
Subject: Re: Wait for background processes to complete
Message-Id: <c4fbcaf2-d4b5-472f-ad1a-0bdb75308412@j20g2000hsi.googlegroups.com>
Gentle Persons,
This was a lot of fun. I would like to respond to the various
observations, especially the ones about the Perl Documentation being
misleading.
To begin with, I apologize for my last post (the long one) - upon re-
reading it my language was not clear. I should have said "the
following code works" as opposed to simply "this works AND waits". I
was referring to the code below that sentence. Sorry.
To restate the original task I wanted to solve:
To be able to execute commands in the background and wait for their
completion.
The documentation I am referring to is http://perldoc.perl.org/.
If you search on the concept of "background processes" this
documentation points you to the following in the Language reference >
perlipc > Background Process :
<begin quote>
You can run a command in the background with:
system("cmd &");
The command's STDOUT and STDERR (and possibly STDIN, depending on your
shell) will be the same as the parent's. You won't need
to catch SIGCHLD because of the double-fork taking place (see below
for more details).
<end quote>
There is no further reference to a "double fork" (except in the
perlfaq8 and only in the context of zombies, which it says are not an
issue using system("cmd &") ). This is confusing.
The documentation for wait(), waitpid() and fork() do not explain that
the executing code should be placed in the "child" section of the if
construct. Some of the examples in perlipc show code occurring in both
the parent and the child section - so it is still not clear. If it
were, why was I insisting on trying to execute the "cp" command in the
parent section? So, thank you Peter for clearing that up. To be fair,
the only place where the "if" construct is indeed placed on paper (or
virtual paper) is the camel book - but it is also not clear where the
code should be placed. But clearly, that is clear now :).
Furthermore, while the perlipc section is quite verbose, nowhere is
the code snippet do {$x=wait; print "$x\n"} until $x==-1 or any
variation of that wait() call mentioned. There are references to a
while loop and the waitpid() function, but being in the context of a
signal handler and 'reaping' - it is not clear.
So, once again many thanks for the help. I would like to know, Peter,
are you in a position to amend the documentation? Also, the perlfaq8
does come closer to explaining, but it is simply not clear how the
fork process will emulate the Unix background operator (&). So how can
we make this better? How's about this:
In the perlipc, under background tasks. make the statement - "the call
system("cmd &") will run the cmd in the background, but will spawn a
shell to execute the command, dispatch the command, terminate the
shell and return to the calling program. The calling program will lose
the ability to wait for the process as is customary with the shell
script command 'wait'. In order to both execute one or more programs
in the background and have the calling program wait for the executions
to complete it will be necessary to use the fork() function."
Then in the fork section. Show a simple example like the ones we have
been working with AND show a simple approach to using the wait
function. Furthermore - add sample code to the wait() and fork()
functions that are simple and realistic, unlike the code same in the
waitpid() function.
In closing, it is perhaps non-intuitive to me that a fork process
should have the child section actually executing the code, but I ask
you how one can intuit that from the sample in the camel book and the
samples in the http://perldoc.perl.org/. To really drive the point
home, Xho's code:
fork or exec("cp $_ $_.old") ;
do {$x=wait;} until $x==-1 ;
Is STILL not intuitive that the child is executing the code!
All in all, with the collective help of y'all I been able to
successfully accomplish my goal, but man it was an uphill battle that
could have been very easily solved with better documentation. But -
what I can't figure out is why I had to embark on this journey in a
new posting - has no-one needed to do this before? Oh well...
so long and thanks for all the fish,
pg
------------------------------
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 1212
***************************************
