[32791] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 4055 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Oct 14 09:09:41 2013

Date: Mon, 14 Oct 2013 06:09:05 -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           Mon, 14 Oct 2013     Volume: 11 Number: 4055

Today's topics:
        Can't Perl Be Event Driven Too? <jblack@nospam.com>
    Re: Can't Perl Be Event Driven Too? <marius@ieval.ro>
    Re: Can't Perl Be Event Driven Too? <vilain@NOspamcop.net>
    Re: Can't Perl Be Event Driven Too? <rweikusat@mobileactivedefense.com>
    Re: multiple codepages <derykus@gmail.com>
    Re: multiple codepages <rweikusat@mobileactivedefense.com>
    Re: multiple codepages <ben@morrow.me.uk>
    Re: multiple codepages <derykus@gmail.com>
    Re: multiple codepages <rweikusat@mobileactivedefense.com>
    Re: sendmail not working - any alternatives? <vilain@NOspamcop.net>
    Re: sendmail not working - any alternatives? <John.Smith@invalid.com>
    Re: sendmail not working - any alternatives? <rweikusat@mobileactivedefense.com>
    Re: sendmail not working - any alternatives? <vilain@NOspamcop.net>
    Re: sendmail not working - any alternatives? <John.Smith@invalid.com>
    Re: sendmail not working - any alternatives? <vilain@NOspamcop.net>
    Re: sendmail not working - any alternatives? <rweikusat@mobileactivedefense.com>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Sun, 13 Oct 2013 23:45:43 -0500
From: John Black <jblack@nospam.com>
Subject: Can't Perl Be Event Driven Too?
Message-Id: <MPG.2cc532f3c40fb07d98978b@news.eternal-september.org>

I keep hearing about how Javascript / Node.js is great for web servers because its "event 
driven" and "non-blocking"...  Statements like this are often made: "JavaScript happens to be 
a great fit for writing servers due to its event-driven nature."

But how hard is it to use Perl for an event driven application like a web server.  Seems to 
me you can just have a main thread processing the event requests.  For each request, it 
spawns a thread to go off and do the work which reports back when done.  The main event 
queueing thread is not "blocked" while the other threads are doing the work.  Presto - event 
driven...  What am I missing?

John Black



------------------------------

Date: Mon, 14 Oct 2013 11:04:06 +0300
From: Marius Gavrilescu <marius@ieval.ro>
Subject: Re: Can't Perl Be Event Driven Too?
Message-Id: <87mwmce0sp.fsf@ieval.ro>

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

John Black <jblack@nospam.com> writes:

> But how hard is it to use Perl for an event driven application like a
> web server.

Very easy.

> Seems to=20
> me you can just have a main thread processing the event requests.  For ea=
ch request, it=20
> spawns a thread to go off and do the work which reports back when done.  =
The main event=20
> queueing thread is not "blocked" while the other threads are doing the wo=
rk.  Presto - event=20
> driven...  What am I missing?

Event driven generally means there's only one thread doing
everything. Threads are costly, thus your setup cannot serve many
concurrent connections.

However, there are POE [0] and AnyEvent [1], which are great for doing
event-driven stuff with Perl.

[0]: http://search.cpan.org/~rcaputo/POE-1.356/lib/POE.pm
[1]: http://search.cpan.org/~mlehmann/AnyEvent-7.05/lib/AnyEvent.pm
=2D-=20
Marius Gavrilescu

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN xxx SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQIcBAEBCgAGBQJSW6V2AAoJEMoENb5ewbNi02MP/jwngoF1tWzCe5y5Rdeg8lQS
AQL8iXIHY8niXaUsqt4yRoeYT84hHSd6c69mRnOJN8d8UezgVT2zAU2DABYp9JkH
cBxuLhy6JQCMMFVwBn88dFq0gQ1Au4t6SL/VlL3v/1/caEkUDqkKQeVGv+hV74nm
r2MXhAtrnz6pMA64rU5ToQ2VUJ/orOiBJPVNug7SjWcF6uuJYcSBS8PtrsoJGIJU
DYgS2PZKF2RYu4Zi4zcXYcpaiyriDoIO+6JCErO2Yd0izKgmrsEbHjXHQAn0OIRc
52rlEFoRMI4KNhKIm0I+5DXafQLzp+vZx/dwu2EsbbRFzfAlUQroWlAlOiCVEb91
nmbAcyk7fE9s6JBikx4YeHlG1nkpr3xp0ippIr0iS78Z2rbDtAG4vMlAVwH81fFU
pePWYx9Lnfj/HNRVVp+/pp5S9vRuYEVthsJhjbr3FNClzZtyBL5wdgSkkjrkdlJJ
e9+16rWnb/Pq54FNTMLTlXo2QIbjwwocC8ttvdjEkppQR0x7SsnHn84pdDBk/DdW
cqTPOVSiY625lKSkljtCd1rAHfkPq2upCWblZ7I76UrrjPOy1QsvPoXvw6T44B6f
NEHpfe+RafUDZ4g3qRUvh5QcwWzpaXE+TUmABDXM5av0iA0ak9vtuDauULERpEVZ
0fHIk+ZfmB/+lplCPiaK
=yIOb
-----END PGP SIGNATURE-----
--=-=-=--


------------------------------

Date: Mon, 14 Oct 2013 01:09:27 -0700
From: Michael Vilain <vilain@NOspamcop.net>
Subject: Re: Can't Perl Be Event Driven Too?
Message-Id: <vilain-6D0B37.01092714102013@news.individual.net>

In article <MPG.2cc532f3c40fb07d98978b@news.eternal-september.org>,
 John Black <jblack@nospam.com> wrote:

> I keep hearing about how Javascript / Node.js is great for web servers 
> because its "event 
> driven" and "non-blocking"...  Statements like this are often made: 
> "JavaScript happens to be 
> a great fit for writing servers due to its event-driven nature."
> 
> But how hard is it to use Perl for an event driven application like a web 
> server.  Seems to 
> me you can just have a main thread processing the event requests.  For each 
> request, it 
> spawns a thread to go off and do the work which reports back when done.  The 
> main event 
> queueing thread is not "blocked" while the other threads are doing the work.  
> Presto - event 
> driven...  What am I missing?
> 
> John Black

What are you trying to do?  You're asking general questions with massive 
assumptions behind them.  It's like asking if a bus will get you to 
Detroit when all you may really need is to get to the library down the 
road.

And yes, perl code can be written to sit in a loop looking for events.  
It's more for procedural programming but it can also do OOP.

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]




------------------------------

Date: Mon, 14 Oct 2013 12:51:14 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Can't Perl Be Event Driven Too?
Message-Id: <87fvs42hql.fsf@sable.mobileactivedefense.com>

John Black <jblack@nospam.com> writes:
> I keep hearing about how Javascript / Node.js is great for web servers
> because its "event driven" and "non-blocking"...  Statements like this
> are often made: "JavaScript happens to be a great fit for writing
> servers due to its event-driven nature."

This statement doesn't mean very much except that the person who made it
is almost certainly repeating something she heard elsewhere without
actually knowing what the terms mean. 

> But how hard is it to use Perl for an event driven application like a
> web server.  Seems to me you can just have a main thread processing
> the event requests.  For each request, it spawns a thread to go off
> and do the work which reports back when done.  The main event queueing
> thread is not "blocked" while the other threads are doing the work.
> Presto - event driven...  What am I missing?

NB: The text below is heavily simplified in order to explain the general
principle.

'Blocked' usually means 'process called into the kernel in order to
receive input on file descriptor ... and now waits until some is
available'. In a situation where many independent clients talk to a
single server using individual TCP connections, eg, in a web server, the
server obviously can't block on a single connection until input data
becomes available and continue to deal with the connections of other
clients at the same time. A so-called 'concurrent TCP server' is needed
in this case. A simple way to provide that is to create a new process
(or thread, although perl threads are not light-weight compared to perl
processes) per client so that each process deal with exactly one TCP
connection and is thus free to make potentially blocking I/O calls as it
suits it. A somewhat more complicated but usually more efficient way is
to use a so-called 'event-driven server': In this case, the process
blocks in system call which waits for input ('events') on multiple file
descriptors concurrently. As soon as data becomes available on any of
them, the process returns to userspace, reads the available data and
continues "where it left of last time" (based on somehow recorded state
information) for this TCP connection and then the next and the next and
so on, until all available input has been consumed. Afterwards, it goes
to the 'wait for something to happen'.

Unfortunately, the only thing perl supports out of the box for this is
select (which has two meanings in Perl) which is the oldest (AFAIK,
invented for 4.2BSD) API providing this facility and the most widely
supported (meaning, it will work on Windows as badly as anywhere
else). Depending on the system you are using (or 'the systems you plan
to support') other interface with more or less useful/ sensible perl
support may be available.

Because 'generalized event loop' (with 'cooperative userspace threading'
hiding ready to ambush in some dark corner nearby) is an all-time
classic of recreational programming, you'll also find uncountable
numbers of mutually incompatible 'generalized event loop' implementation
on CPAN (most of them presumably abandonware).


------------------------------

Date: Sat, 12 Oct 2013 20:15:50 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: multiple codepages
Message-Id: <c6166d56-1883-4b96-9095-07c0db731cc9@googlegroups.com>

On Saturday, October 12, 2013 12:46:32 PM UTC-7, Dr.Ruud wrote:
> On 12/10/2013 01:55, C.DeRykus wrote: 
> 
> >  *foo = eval "\\$tmp"; die $@ if $@ ;
> 
> I never get it why people test $@.
> 

Reflex.

>    eval "*foo = \\$tmp; 1" or die $@;
> 
> And if you are going to die anyway:
>
>    *foo = \$tmp;
     ^^^^^^^^^^^^^
No this is not the same... with or without an
eval in the mix.

The idea is to make $foo read-only outside
the sub so you'd need something more like: 

    eval "*foo = \\$tmp;";


-- 
Charles DeRykus


------------------------------

Date: Sun, 13 Oct 2013 19:10:29 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: multiple codepages
Message-Id: <87d2n93uui.fsf@sable.mobileactivedefense.com>

"C.DeRykus" <derykus@gmail.com> writes:
> On Tuesday, October 8, 2013 4:59:11 AM UTC-7, Rainer Weikusat wrote:
>> Charles DeRykus <derykus@gmail.com> writes:

[difference between lexically scoped our and my]

> Yes, thanks I realize that.  My point was although it was a loose
> "encapsulation" you can come close to faking what 'state' and
> 'my-variables in a surrounding scope' can do.

Well, nobody ever doubted that all this outlandish, newfangled stuff
like "lexically scoped objects" isn't really necessary since dynamically
scoped ('global') variables is really all that's needed To Get The Job
Done[tm], and someone who can't be bothered with exercising the
necessary care to do so has no business programming computer
anyway. This will also be much better for performance!

I'm sorry but I don't quite understand the purpose of this crusade. I'm
also not trying to convince anyone that he shouldn't "just use global
variables" whenever he considers that sensible, I was just trying
explain the difference between an object that's private to a subroutine
and an object owned by the containing package.

> In fact, although it's nothing more than a curiosity,
> (maybe "curioser and curioser" Alice would say) you could 
> even tighten it a bit more with an eval:
>  
> package MyFoo;
>    our( $foo, $tmp );
>    sub add_something {
>      local $tmp = $foo;
>      $tmp += $_[0];
>      *foo = eval "\\$tmp"; die $@ if $@ ;
>      return $foo;
>   }
>
>
> Now an injection of $MyFoo::foo = -17 won't be possible.

package MyFoo;
   our( $foo, $tmp );
sub add_something {
    local $tmp = $foo;
    $tmp += $_[0];
    *foo = eval "\\$tmp";
    return $foo;
}

package SatanicLaughter;

use overload
    '+' => sub {
	my $self = $_[0];

	print STDERR ("I'm the lord of inverse and bring you subtraction!\n");
	return $$self -= $_[1];
    };


sub new
{
    my $self;

    $self = $_[1];
    return bless(\$self, $_[0]);
}

package FoosRUs;

print MyFoo::add_something(14), "\n";

my $x = SatanicLaughter->new($MyFoo::foo);
*MyFoo::foo = \$x;

print MyFoo::add_something(15), "\n";


------------------------------

Date: Sun, 13 Oct 2013 23:31:05 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: multiple codepages
Message-Id: <9ijria-e2u.ln1@anubis.morrow.me.uk>


Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
> "C.DeRykus" <derykus@gmail.com> writes:
> > On Tuesday, October 8, 2013 4:59:11 AM UTC-7, Rainer Weikusat wrote:
> >> Charles DeRykus <derykus@gmail.com> writes:
> 
> [difference between lexically scoped our and my]

ITYM dynamically?

> > Yes, thanks I realize that.  My point was although it was a loose
> > "encapsulation" you can come close to faking what 'state' and
> > 'my-variables in a surrounding scope' can do.
> 
> Well, nobody ever doubted that all this outlandish, newfangled stuff
> like "lexically scoped objects" isn't really necessary since dynamically
> scoped ('global') variables is really all that's needed To Get The Job
> Done[tm], and someone who can't be bothered with exercising the
> necessary care to do so has no business programming computer
> anyway. This will also be much better for performance!

It isn't, actually. Perl lexicals are a decent bit faster than Perl
globals.

Ben



------------------------------

Date: Sun, 13 Oct 2013 23:11:03 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: multiple codepages
Message-Id: <7209fea4-8205-45df-81b0-548920b6ec64@googlegroups.com>

On Sunday, October 13, 2013 11:10:29 AM UTC-7, Rainer Weikusat wrote:
> "C.DeRykus" <derykus@gmail.com> writes:
> 
> > On Tuesday, October 8, 2013 4:59:11 AM UTC-7, Rainer Weikusat wrote:
>

 ....

use Scalar::Util qw(blessed);
 
> package MyFoo;
>    our( $foo, $tmp );
> sub add_something {

     my $class = Scalar::Util::blessed( $foo );
    die <<END if $class;
Regretfully, the church had to perform an unscheduled exorcism of a potentially satanic blessing. This church must insist all supplicants enter unblessed at this time.  Thank you for your understanding and good will."
END

>     local $tmp = $foo;
>     $tmp += $_[0];
>     *foo = eval "\\$tmp";
>     return $foo;
> }
> 
> package SatanicLaughter;
> use overload
> 
>     '+' => sub {
> 	my $self = $_[0];
> 
> 	print STDERR ("I'm the lord of inverse and bring you subtraction!\n");
>
> 	return $$self -= $_[1]; 
>     };
> 
> sub new
> {
>     my $self;
>     $self = $_[1];
>     return bless(\$self, $_[0]);
> }
> 
> package FoosRUs;
> 
> print MyFoo::add_something(14), "\n";
> my $x = SatanicLaughter->new($MyFoo::foo);
> *MyFoo::foo = \$x;
> 
> print MyFoo::add_something(15), "\n";

-- 
Charles DeRykus


------------------------------

Date: Mon, 14 Oct 2013 11:47:09 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: multiple codepages
Message-Id: <87r4bow2mq.fsf@sable.mobileactivedefense.com>

"C.DeRykus" <derykus@gmail.com> writes:
> On Sunday, October 13, 2013 11:10:29 AM UTC-7, Rainer Weikusat wrote:
>> "C.DeRykus" <derykus@gmail.com> writes:
>> > On Tuesday, October 8, 2013 4:59:11 AM UTC-7, Rainer Weikusat wrote:
>>
>
> ....
>
> use Scalar::Util qw(blessed);
>  
>> package MyFoo;
>>    our( $foo, $tmp );
>> sub add_something {
>
>      my $class = Scalar::Util::blessed( $foo );
>     die <<END if $class;
> Regretfully, the church had to perform an unscheduled exorcism of a potentially satanic blessing. This church must insist all supplicants enter unblessed at this time.  Thank you for your understanding and good will."
> END
>
>>     local $tmp = $foo;
>>     $tmp += $_[0];
>>     *foo = eval "\\$tmp";
>>     return $foo;
>> }

package FoosRUs;

print MyFoo::add_something(14), "\n";

my $x = SatanicLaughter->new($MyFoo::foo);
*MyFoo::foo = \$x;

my $blessed = \&Scalar::Util::blessed;
*Scalar::Util::blessed = sub($) {
    if (caller() eq 'MyFoo') {
	print STDERR <<TT;
The economy has been turned around in your area and the
IT system of the contractor who pockets the money for
providing what used to be this service doesn't (yet)
work as you might have come to expect.

Because this doesn't cost us anything, we apologize for
any inconvenience caused.

TT
	return;
    }
    
    &$blessed;
};


print MyFoo::add_something(15), "\n";


------------------------------

Date: Sat, 12 Oct 2013 16:20:27 -0700
From: Michael Vilain <vilain@NOspamcop.net>
Subject: Re: sendmail not working - any alternatives?
Message-Id: <vilain-077BCE.16202712102013@news.individual.net>

In article <dq6j59p7lljlu88cefdguvlfcelhh8arm0@4ax.com>,
 John <John.Smith@invalid.com> wrote:

> My web site provider has trouble getting sendmail to work.
> 
> This is a trimmed down versio on a perl file that used to work just fine for
> years and then it quit working. I've contacted them to no avail:
> 
> 
> #!/usr/bin/perl
> print "Content-Type: text/html; charset=iso-8859-1\n\n";
> print '<html><head>';
> print '<meta http-equiv="Content-Type" content="text/html; 
> charset=iso-8859-1">';
> print '</head><body>';
> $i=0;
> &testmail;
> print "Testing email $i <br>(1=success, 0=fail)<br>";
> print "</body></HTML>";
> 
> sub testmail
> {
> #open(MAIL,"|/usr/sbin/sendmail -t") || return 0;
> open(MAIL,"|/usr/lib/sendmail -t") || return 0;
> #open(MAIL,"|/usr/bin/sendmail -t") || return 0;
> select (MAIL);
> print "To: blahblah\@whatever.com\n";
> print "From: blahblah\@whatever.com\n";
> print "Subject: testing\n";
> print "\n";
> print "This is message.\n";
> close(MAIL);
> select (STDOUT);
> $i=1;
> }
> 
> The code returns:
> 
> "Testing email 1
> (1=success, 0=fail)"
> 
> but no email ever gets to the receiver (yes, I tried with actual working
> addresses).
> 
> It works just fine on another domain host provider but I need to get it to 
> work
> on this particular.
> 
> What alternatives can I try?

Look in the log files for mail on your web site provider. See if mail is 
actually being sent out by the perl script.  If it is, then the perl 
works. What's happening once it leaves the machine is anyone's 
guess--spam filter or blocker or maybe someone doesn't like you.

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]




------------------------------

Date: Sun, 13 Oct 2013 10:59:27 +0300
From: John <John.Smith@invalid.com>
Subject: Re: sendmail not working - any alternatives?
Message-Id: <rkkk59pv9m018cp77btprbr5un4t9ftgrk@4ax.com>

Michael Vilain <vilain@NOspamcop.net> wrote:

>In article <dq6j59p7lljlu88cefdguvlfcelhh8arm0@4ax.com>,
> John <John.Smith@invalid.com> wrote:
>
>> My web site provider has trouble getting sendmail to work.
>> 
>> This is a trimmed down versio on a perl file that used to work just fine for
>> years and then it quit working. I've contacted them to no avail:
>> 
>> 
>> #!/usr/bin/perl
>> print "Content-Type: text/html; charset=iso-8859-1\n\n";
>> print '<html><head>';
>> print '<meta http-equiv="Content-Type" content="text/html; 
>> charset=iso-8859-1">';
>> print '</head><body>';
>> $i=0;
>> &testmail;
>> print "Testing email $i <br>(1=success, 0=fail)<br>";
>> print "</body></HTML>";
>> 
>> sub testmail
>> {
>> #open(MAIL,"|/usr/sbin/sendmail -t") || return 0;
>> open(MAIL,"|/usr/lib/sendmail -t") || return 0;
>> #open(MAIL,"|/usr/bin/sendmail -t") || return 0;
>> select (MAIL);
>> print "To: blahblah\@whatever.com\n";
>> print "From: blahblah\@whatever.com\n";
>> print "Subject: testing\n";
>> print "\n";
>> print "This is message.\n";
>> close(MAIL);
>> select (STDOUT);
>> $i=1;
>> }
>> 
>> The code returns:
>> 
>> "Testing email 1
>> (1=success, 0=fail)"
>> 
>> but no email ever gets to the receiver (yes, I tried with actual working
>> addresses).
>> 
>> It works just fine on another domain host provider but I need to get it to 
>> work
>> on this particular.
>> 
>> What alternatives can I try?
>
>Look in the log files for mail on your web site provider. See if mail is 
>actually being sent out by the perl script.  If it is, then the perl 
>works. What's happening once it leaves the machine is anyone's 
>guess--spam filter or blocker or maybe someone doesn't like you.


I can't find any log files using FileZilla.


------------------------------

Date: Sun, 13 Oct 2013 19:20:34 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: sendmail not working - any alternatives?
Message-Id: <8761t13udp.fsf@sable.mobileactivedefense.com>

John <John.Smith@invalid.com> writes:
> My web site provider has trouble getting sendmail to work.
>
> This is a trimmed down versio on a perl file that used to work just fine for
> years and then it quit working. I've contacted them to no avail:

[...]

> open(MAIL,"|/usr/lib/sendmail -t") || return 0;

[...]

If you can create files on this machine, you could make that something
like

open(MAIL, '| /usr/sbin/sendmail -tv >/tmp/sendmail 2>&1')

This will put a trace of any SMP-conversation into /tmp/sendmail which
might help with debugging this.


------------------------------

Date: Sun, 13 Oct 2013 13:08:23 -0700
From: Michael Vilain <vilain@NOspamcop.net>
Subject: Re: sendmail not working - any alternatives?
Message-Id: <vilain-CE1F09.13082313102013@news.individual.net>

In article <rkkk59pv9m018cp77btprbr5un4t9ftgrk@4ax.com>,
 John <John.Smith@invalid.com> wrote:

> Michael Vilain <vilain@NOspamcop.net> wrote:
> 
> >In article <dq6j59p7lljlu88cefdguvlfcelhh8arm0@4ax.com>,
> > John <John.Smith@invalid.com> wrote:
> >
> >> My web site provider has trouble getting sendmail to work.
> >> 
> >> This is a trimmed down versio on a perl file that used to work just fine 
> >> for
> >> years and then it quit working. I've contacted them to no avail:
> >> 
> >> 
> >> #!/usr/bin/perl
> >> print "Content-Type: text/html; charset=iso-8859-1\n\n";
> >> print '<html><head>';
> >> print '<meta http-equiv="Content-Type" content="text/html; 
> >> charset=iso-8859-1">';
> >> print '</head><body>';
> >> $i=0;
> >> &testmail;
> >> print "Testing email $i <br>(1=success, 0=fail)<br>";
> >> print "</body></HTML>";
> >> 
> >> sub testmail
> >> {
> >> #open(MAIL,"|/usr/sbin/sendmail -t") || return 0;
> >> open(MAIL,"|/usr/lib/sendmail -t") || return 0;
> >> #open(MAIL,"|/usr/bin/sendmail -t") || return 0;
> >> select (MAIL);
> >> print "To: blahblah\@whatever.com\n";
> >> print "From: blahblah\@whatever.com\n";
> >> print "Subject: testing\n";
> >> print "\n";
> >> print "This is message.\n";
> >> close(MAIL);
> >> select (STDOUT);
> >> $i=1;
> >> }
> >> 
> >> The code returns:
> >> 
> >> "Testing email 1
> >> (1=success, 0=fail)"
> >> 
> >> but no email ever gets to the receiver (yes, I tried with actual working
> >> addresses).
> >> 
> >> It works just fine on another domain host provider but I need to get it to 
> >> work
> >> on this particular.
> >> 
> >> What alternatives can I try?
> >
> >Look in the log files for mail on your web site provider. See if mail is 
> >actually being sent out by the perl script.  If it is, then the perl 
> >works. What's happening once it leaves the machine is anyone's 
> >guess--spam filter or blocker or maybe someone doesn't like you.
> 
> 
> I can't find any log files using FileZilla.

The mail transfer agent is most likely a service that's managed by the 
web hosting company. You'll have to contact them for a copy, if they'll 
even provide it at all.

If you're using a shared hosting facility, I'd look at moving your 
hosting to a VM instead.  You'll have to manage everything, but you'll 
have more control over such things as email and the web server for your 
site.  Your call on if it's worthwhile.

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]




------------------------------

Date: Mon, 14 Oct 2013 09:52:12 +0300
From: John <John.Smith@invalid.com>
Subject: Re: sendmail not working - any alternatives?
Message-Id: <h05n59dfmseg6rdkdg4cggcriifu2fqfv5@4ax.com>

Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:

>John <John.Smith@invalid.com> writes:
>> My web site provider has trouble getting sendmail to work.
>>
>> This is a trimmed down versio on a perl file that used to work just fine for
>> years and then it quit working. I've contacted them to no avail:
>
>[...]
>
>> open(MAIL,"|/usr/lib/sendmail -t") || return 0;
>
>[...]
>
>If you can create files on this machine, you could make that something
>like
>
>open(MAIL, '| /usr/sbin/sendmail -tv >/tmp/sendmail 2>&1')
>
>This will put a trace of any SMP-conversation into /tmp/sendmail which
>might help with debugging this.


I looked up the man page fro meaning on -tv but could not find explanation. What
does -tv >/tmp/sendmail 2>&1

I tried it and got no log file. I also tried 
$i3=open(MAIL,"|/usr/sbin/sendmail -tv >test.txt") || return 0;

where $i3 gets a number but no test.txt is created.


------------------------------

Date: Mon, 14 Oct 2013 01:06:11 -0700
From: Michael Vilain <vilain@NOspamcop.net>
Subject: Re: sendmail not working - any alternatives?
Message-Id: <vilain-C369DB.01061114102013@news.individual.net>

In article <h05n59dfmseg6rdkdg4cggcriifu2fqfv5@4ax.com>,
 John <John.Smith@invalid.com> wrote:

> Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> 
> >John <John.Smith@invalid.com> writes:
> >> My web site provider has trouble getting sendmail to work.
> >>
> >> This is a trimmed down versio on a perl file that used to work just fine 
> >> for
> >> years and then it quit working. I've contacted them to no avail:
> >
> >[...]
> >
> >> open(MAIL,"|/usr/lib/sendmail -t") || return 0;
> >
> >[...]
> >
> >If you can create files on this machine, you could make that something
> >like
> >
> >open(MAIL, '| /usr/sbin/sendmail -tv >/tmp/sendmail 2>&1')
> >
> >This will put a trace of any SMP-conversation into /tmp/sendmail which
> >might help with debugging this.
> 
> 
> I looked up the man page fro meaning on -tv but could not find explanation. 
> What
> does -tv >/tmp/sendmail 2>&1
> 
> I tried it and got no log file. I also tried 
> $i3=open(MAIL,"|/usr/sbin/sendmail -tv >test.txt") || return 0;
> 
> where $i3 gets a number but no test.txt is created.

http://www.sendmail.org/~ca/email/doc8.12/op-sh-3.html#sh-3

will show you that true sendmail run with -tv will run it in test mode 
with VERBOSE logging out put to a file.  Are you sure your web host is 
even running sendmail and not postfix or some other mail transfer agent?  
Just because the program is there doesn't mean it's setup.  Does ps show 
it running?

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]




------------------------------

Date: Mon, 14 Oct 2013 12:30:44 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: sendmail not working - any alternatives?
Message-Id: <87k3hg2ior.fsf@sable.mobileactivedefense.com>

John <John.Smith@invalid.com> writes:
> Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>>John <John.Smith@invalid.com> writes:
>>> My web site provider has trouble getting sendmail to work.
>>>
>>> This is a trimmed down versio on a perl file that used to work just fine for
>>> years and then it quit working. I've contacted them to no avail:
>>
>>[...]
>>
>>> open(MAIL,"|/usr/lib/sendmail -t") || return 0;
>>
>>[...]
>>
>>If you can create files on this machine, you could make that something
>>like
>>
>>open(MAIL, '| /usr/sbin/sendmail -tv >/tmp/sendmail 2>&1')
>>
>>This will put a trace of any SMP-conversation into /tmp/sendmail which
>>might help with debugging this.
>
>
> I looked up the man page fro meaning on -tv but could not find explanation. What
> does -tv >/tmp/sendmail 2>&1

That's really the same as -t -v. 

> I tried it and got no log file. I also tried 
> $i3=open(MAIL,"|/usr/sbin/sendmail -tv >test.txt") || return 0;
>
> where $i3 gets a number but no test.txt is created.

Judgeing from your original posting, the sendmail binary you were
invoking resided in /usr/lib and not /usr/sbin. 'No test.txt is created'
suggests that your perl process is not allowed to create files in the
directory in question. The return value of the open just tells you if
forking a new process succeeded (it will then be the process ID of this
process). Problems encountered by the shell while trying to execute the
actual command _may_ manifest themselves in form of a non-zero $? after
the handle has been closed.



------------------------------

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:

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests. 

#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 4055
***************************************


home help back first fref pref prev next nref lref last post