[19992] in Perl-Users-Digest
Perl-Users Digest, Issue: 2187 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Nov 23 00:10:40 2001
Date: Thu, 22 Nov 2001 21:10:09 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <1006492208-v10-i2187@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Thu, 22 Nov 2001 Volume: 10 Number: 2187
Today's topics:
Signal Handlers (Stuart Allen)
Re: Signal Handlers <ilya@martynov.org>
Re: using sendmail from perl nobull@mail.com
Re: using sendmail from perl <admin@asarian-host.net>
Re: variable scope <matthew.garrish@sympatico.ca>
Re: variable scope (Chris Fedde)
Re: variable scope (Chris Fedde)
Re: variable scope <wyzelli@yahoo.com>
Re: variable scope (Chris Fedde)
webstore (J)
Re: webstore <jeff@vpservices.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 22 Nov 2001 15:16:05 -0800
From: stuart@jacl.animats.net (Stuart Allen)
Subject: Signal Handlers
Message-Id: <b2ce9981.0111221516.2fc02007@posting.google.com>
I have written a daemon in Perl that forks then waits to receive a
SIGUSR2. When it receives the signal, it calls a handler that checks a
database for outstanding messages then passes them on. The question I
have is what happens if the program receives another SIGUSR2 while in
the middle of executing the handler. Is there anyway to make the
signal block until the handler has finished running before being run
again?
Regards,
Stuart
------------------------------
Date: 23 Nov 2001 05:30:41 +0300
From: Ilya Martynov <ilya@martynov.org>
Subject: Re: Signal Handlers
Message-Id: <87vgg243se.fsf@abra.ru>
>>>>> On 22 Nov 2001 15:16:05 -0800, stuart@jacl.animats.net (Stuart Allen) said:
Stuart> I have written a daemon in Perl that forks then waits to receive a
Stuart> SIGUSR2. When it receives the signal, it calls a handler that checks a
Stuart> database for outstanding messages then passes them on. The question I
Stuart> have is what happens if the program receives another SIGUSR2 while in
Stuart> the middle of executing the handler. Is there anyway to make the
Stuart> signal block until the handler has finished running before being run
Stuart> again?
Usually it is better to avoid doing anything serious inside signal
handler. Very common aproach is setting some flag variable inside
signal handler and exit from it. Main code should poll this variable
for changes. If it becomes true you do signal handling and once it
finished reset this flag variable to false.
If you do signal handling this way you code will ignore SIGUSR2
recieved during signal handling.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Ilya Martynov (http://martynov.org/) TIV.net (http://tiv.net/) |
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
------------------------------
Date: 21 Nov 2001 18:11:22 +0000
From: nobull@mail.com
Subject: Re: using sendmail from perl
Message-Id: <u9n11g8051.fsf@wcl-l.bham.ac.uk>
"Zachary Kent" <zkent@adelphia.net> writes:
> <nobull@mail.com> wrote in message news:u9elmts3h8.fsf@wcl-l.bham.ac.uk...
> > "Zachary Kent" <zkent@adelphia.net> writes:
> >
> > > open (MAIL, "|/usr/sbin/sendmail -t") or error("Can't open sendmail");
> > > print MAIL ("To: $regEmail\n");
> >
> > > The problem arises when someone has put an invalid character (comma,
> space,
> > > or >) in their address. Instead of a graceful warning or something I
> get a
> > > fatal error that kills my script and leaves the user in Limbo.
> >
> > This seems highly improbable.
>
> I agree. However, its happening.
I see no evidence to support this assertion.
> > Perhaps you should present us with the raw data from which you arrived
> > at the conclusion that an error in sendmail killed your script so that
> > we could provide an alternative interpretation.
> 550 error using the code above.
550 error is not a Perl error, it is a web server error. Have you
looked in the error log?
This usually means that the data comming up the pipe from the CGI
process to the HTTP server process is not a valid CGI response. There
is not sufficient reason from what you've said to infer that your Perl
script terminates abnormally.
To be absolutely sure put add some code in your Perl script that
appends scalar(localtime) to a file. Put this code at a point in your
script after the point at which you believe it is dying. If the
timestamp appears in the file then your hasty concusion that the
script dies is disproved.
At a guess the sendmail process is pumping stuff out on its STDOUT
stream and screwing the CGI response header, or maybe the sendmail
process' STDERR stream is erroneously connected to the CGI response
pipe rather than the HTTP server's error log (eek!).
Try redirecting sendmail's STDERR and STDOUT to /dev/null.
None of this, of course, has anything to do with Perl.
> I have never tried trapping it in an eval. Does that work?
If there were an error occuring in your Perl script it could probably
be caught using eval. However since I doubt that the script is dying
this probably moot.
I'm getting a very stong sense of deja vu here. Please see Bill
Dykstra's thread "Trapping sendmail errors (with eval?)" from
2001-10-03 where I gave basically the same advice I've just given you.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Fri, 23 Nov 2001 03:48:22 GMT
From: "Mark" <admin@asarian-host.net>
Subject: Re: using sendmail from perl
Message-Id: <aGjL7.70298$qx2.3944408@bin5.nnrp.aus1.giganews.com>
"Zachary Kent" <zkent@adelphia.net> wrote in message
news:n1wK7.4246$XJ5.1146978@news1.news.adelphia.net...
> Flame-throwers Ready! I can take it! (at least a little)
>
> Hello, I am using Perl 5.005_03 and Sendmail 8.11.1 on a server I don't
own
> or have root access (your basic leased web account). I am calling
Sendmail
> via Perl in a CGI environment with the following commands:
>
> open (MAIL, "|/usr/sbin/sendmail -t") or error("Can't open sendmail");
> print MAIL ("To: $regEmail\n");
> print MAIL ("From: $config{'helpEmail'}\n");
> print MAIL ("Subject: Enrollment Confirmation (re: Biological Warfare
> broadcast)\n\n");
> print MAIL ("$ebody_w");
> close MAIL;
>
> The problem arises when someone has put an invalid character (comma,
space,
> or >) in their address. Instead of a graceful warning or something I get
a
> fatal error that kills my script and leaves the user in Limbo.
Hi Zachery,
Been there, done that. :) Actually, sendmail does not kill your script; not
directly, at least. It is the output sendmail generates, on such a wrong
address, which throws your web daemon off. Prior to invoking sendmail in
your Perl script, be sure you have already written something like:
print "Content-type: text/html\n\n";
Otherwise your web daemon interpretes the "terminal" output of sendmail
(which now goes directly to your web daemon) as a malformed header, causing
it to die off.
A very quick and dirty method, is this:
open (MAIL, "| /usr/sbin/sendmail -t >/dev/null") or ...
I know, plenty of folks will frown at such a solution. But, since you have
indicated not to be interested really in checking the validity of the email
addresses yourself, adding the ">/dev/null" to the sendmail command WILL
prevent your web daemon from receiving unexpected input.
- Mark
------------------------------
Date: Thu, 22 Nov 2001 18:16:51 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: variable scope
Message-Id: <ZHfL7.16671$op.2854545@news20.bellglobal.com>
"Mark Jason Dominus" <mjd@plover.com> wrote in message
news:3bfd548a.276$276@news.op.net...
>
> Shadowing a loop index variable for its entire scope surely seems like
> more than just bad style to me. I think it is a lot more likely to be
> an error than a lot of the things Perl warns about.
>
You'll never know how happy it made me to read a post where someone
understands the angle I'm coming from. : )
All I've been getting are lectures on why a variable in a new scope should
not cause warnings, which is probably the first thing you need to learn when
beginning Perl. I am not against allowing different variables with the same
name in different scopes, but against the ability to mask an index variable
within the only scope it knows, and not have a warning produced.
I thought it made sense that a variable that only lasts for one iteration of
a loop should be the only variable in that scope allowed to use that name,
and not exist lexically scoped one level removed. I thought it was
reasonable to expect a warning (error, boo-boo or whatever anyone wants to
call it) to be output to let you know this has occurred. It seems, however,
that I'm not expected to think, but just accept.
Thanks again,
Matt
------------------------------
Date: Fri, 23 Nov 2001 04:10:11 GMT
From: cfedde@fedde.littleton.co.us (Chris Fedde)
Subject: Re: variable scope
Message-Id: <D_jL7.444$Fbh.190301696@news.frii.net>
In article <ts%K7.10741$op.2408042@news20.bellglobal.com>,
Matt Garrish <matthew.garrish@sympatico.ca> wrote:
>"Uri Guttman" <uri@stemsystems.com> wrote in message
Words are failing to convince here.
Lets cut to the chase and consider this code:
#!/usr/bin/perl
use strict;
use warnings;
my $s = "outer";
{
my $s = "inner";
for my $s ("loop", "index", "values") {
my $s = "in for with $s";
print "$s\n";
} continue {
print "$s\n";
}
print "$s\n";
}
print "$s\n";
On my system this results in the following non-surprising result.
in for with loop
loop
in for with index
index
in for with values
values
inner
outer
As strange as it might seem this is working as it should.
Good Luck
--
This space intentionally left blank
------------------------------
Date: Fri, 23 Nov 2001 04:18:18 GMT
From: cfedde@fedde.littleton.co.us (Chris Fedde)
Subject: Re: variable scope
Message-Id: <e6kL7.445$Fbh.170784256@news.frii.net>
In article <Gq%K7.38$9s2.487@vicpull1.telstra.net>,
Wyzelli <wyzelli@yahoo.com> wrote:
>
>my $var;
>{
> my $var;
> foreach $var (@array){
> my $var;
> }
>}
>
>Three completely different scopes. I for one would never have realised that
>without carefully reading this thread and then doing some testing to see
>what masks what.
>
s/Three/Four/ and I will agree with you. The space between the
foreach and the { together with any continue block constitute a
seperate scope. The interior of the foreach block is a fourth scope.
--
This space intentionally left blank
------------------------------
Date: Fri, 23 Nov 2001 14:06:50 +0930
From: "Wyzelli" <wyzelli@yahoo.com>
Subject: Re: variable scope
Message-Id: <xmkL7.32$gG2.409@vicpull1.telstra.net>
"Chris Fedde" <cfedde@fedde.littleton.co.us> wrote in message
news:e6kL7.445$Fbh.170784256@news.frii.net...
> In article <Gq%K7.38$9s2.487@vicpull1.telstra.net>,
> Wyzelli <wyzelli@yahoo.com> wrote:
> >
> >my $var;
> >{
> > my $var;
> > foreach $var (@array){
> > my $var;
> > }
> >}
> >
> >Three completely different scopes. I for one would never have realised
that
> >without carefully reading this thread and then doing some testing to see
> >what masks what.
> >
>
> s/Three/Four/ and I will agree with you. The space between the
> foreach and the { together with any continue block constitute a
> seperate scope. The interior of the foreach block is a fourth scope.
Uh, yeah, but the second scope in the above example is illustrative only (as
a logical equivalecy).
Wyzelli
--
($a,$b,$w,$t)=(' bottle',' of beer',' on the wall','Take one down, pass it
around');
for(reverse(1..100)){$s=($_!=1)?'s':'';$c.="$_$a$s$b$w\n$_$a$s$b\n$t\n";
$_--;$s=($_!=1)?'s':'';$c.="$_$a$s$b$w\n\n";}print"$c*hic*";
------------------------------
Date: Fri, 23 Nov 2001 04:43:58 GMT
From: cfedde@fedde.littleton.co.us (Chris Fedde)
Subject: Re: variable scope
Message-Id: <iukL7.447$Fbh.171021312@news.frii.net>
In article <3bfd548a.276$276@news.op.net>,
Mark Jason Dominus <mjd@plover.com> wrote:
>In article <m3vgg27m4f.fsf@mumonkan.sunstarsys.com>,
>
>For example, in Edsger Dijkstra's _A Discipline of Programming_, the
>examples are written in a language in which lexical variables from
>outer blocks do *not* automatically extend their scope to include
>inner blocks.
>
Edsger Dijkstra also describes programmers as "the secret society for the
creation and preservation of artificial complexity." I think that this
thread serves as some kind of argument for that position.
Good Luck
--
This space intentionally left blank
------------------------------
Date: Fri, 23 Nov 2001 00:02:29 GMT
From: jadapturSPAMNOT@hotmail.com (J)
Subject: webstore
Message-Id: <3bfd4b51.23471089@netnews.worldnet.att.net>
http://www.extropia.com/
Is Extrpia's webstore a robust shopping cart
Please respond via email..
Remove SPAMNOT from the email address to reply.
J
------------------------------
Date: Thu, 22 Nov 2001 16:01:10 -0800
From: Jeff Zucker <jeff@vpservices.com>
Subject: Re: webstore
Message-Id: <3BFD91C6.2F8C5432@vpservices.com>
J wrote:
>
> [SPAM snipped]
>
> Remove SPAMNOT from the email address to reply.
How nice, he sends us spam and then doesn't want any sent to him.
--
Jeff
------------------------------
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.
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 V10 Issue 2187
***************************************
