[26747] in Perl-Users-Digest
Perl-Users Digest, Issue: 8831 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 5 18:05:18 2006
Date: Thu, 5 Jan 2006 15:05:05 -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 Thu, 5 Jan 2006 Volume: 10 Number: 8831
Today's topics:
Re: Are there alternatives to exec and system <joe@inwap.com>
Re: CGI/sendmail help axel@white-eagle.invalid.uk
Re: IO::Pipe and loss of data xhoster@gmail.com
Line gives syntax error <mdudley@king-cart.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 05 Jan 2006 12:46:25 -0800
From: Joe Smith <joe@inwap.com>
Subject: Re: Are there alternatives to exec and system
Message-Id: <I-qdnXLuhro5GCDeRVn-ow@comcast.com>
Daniel Kaplan wrote:
> I would like one of my Perl scripts to "spawn" another Perl script.
>
> However it seems that with exec() my calling app stops running and
> everything goes to the script I exec'd. And that system() freezes my
> calling app and it waits for the new app to complete and return.
Correct. Using system() without "&" says to wait as long as it takes
for the other process to finish before continuing. Using system()
with "&" causes the other process to run independently, in which
case you lose control over it.
Another thing to think about: partial results.
$result = `some command`; # Waits until finished
print "Result = $result\n"; # End result, not partial.
versus
open my $cmd,"some command|" or die;
while (<$cmd>) {
print "Partial result: $_"; # One line at a time
}
print "Finished\n";
-Joe
------------------------------
Date: Thu, 05 Jan 2006 21:44:44 GMT
From: axel@white-eagle.invalid.uk
Subject: Re: CGI/sendmail help
Message-Id: <grgvf.20921$iz3.6785@text.news.blueyonder.co.uk>
Vespasian <ves@ves.net> wrote:
> The first open MAIL always sends an email. The second does not. If
> fact, I got a failure notice from the second one with the following
> error,
[code snipped]
Others have answered your question.
> if (1) {
> open (MAIL, "| /usr/sbin/sendmail -t -f
> \'keepitsimple222\@yahoo.com\'") || print "Opening sendmail failed:
> $!";
> print MAIL "From: tester\@1testdomain.com\r\n";
> print MAIL "To: keepitsimple222\@yahoo.com\r\n";
> print MAIL "Subject: old code 6\r\n";
> print MAIL "Hi there. This script sure works great on UNIX, doesn't
> it?\r\n";
> close (MAIL);
> }
Why when opening sendmail fails, do you continue
to attemt to print to it?
Axel
------------------------------
Date: 05 Jan 2006 21:51:22 GMT
From: xhoster@gmail.com
Subject: Re: IO::Pipe and loss of data
Message-Id: <20060105165122.247$Oo@newsreader.com>
"Genevieve S." <none@here.com> wrote:
> I choped it as much as it was possible, but it did not yet show up the
> error. May be I cut too much, but as the last run of my big script was
> fine for 6 hours before the error appeared I think it is just not easy to
> reproduce the error.
Bummer. That always makes for hard to find problems.
> Anyway I put some code at the end of this message, which should run and
> show at least how I work to send a message and use the pipe.
In your sample code, the message is always short. Is it always about that
size in the real code?
...
> ******************************************************
> These are the remains of my code. But please use with care. It is an
> endless loop so you have to stop it manually and if it runs to long, it
> will have an enormously amount of data in the pipe
That isn't how pipes work. There is a fixed amount of buffer (probably 4K
on your system) for the pipe. If the reader can't keep up with the
writer(s), then that buffer gets full, and writers will block until the
reader has a chance to catch up, making more room in the buffer.
> (this is because in
> original script the line to be sent is assembled after a line of a
> logfile is read via tail. In this version there is always the same line
> to be send, which is very fast and does never have a break between
> lines).
This non-CPU boundness of the real code might be the problem. See comments
below near the eval.
>
> Sadly I must say I did not yet received the error with this...
> As logging of the script is nearly the same in my big one, I'd like to
> show you what I got yesterday:
> my_log>>>>>
> Wed Jan 4 13:22:17 2006 script started 24687
> [...]
> Wed Jan 4 13:49:56 2006 log reader started for 3070: 14508
> Wed Jan 4 19:40:27 2006 Server 3201: Missing message between 54 and 56
> Wed Jan 4 19:40:27 2006 Server 1665: Missing message between 38 and 40
> Wed Jan 4 19:40:30 2006 Server 4002: Missing message between 9 and 11
> Wed Jan 4 19:40:40 2006 Server 3022: Missing message between 52 and 61
> Wed Jan 4 19:55:25 2006 Server 3025: Missing message between 70 and 74
I would make it log the just-received line in it's entirety, not only the
serial number of that line. In fact, the main program should probably
store not just the previous message-id, but the entire previous message,
for each "server". Then, when there seems to be a gap, you can print out
the entire message before, and the entire message after, the gap. That
could help a lot in debugging.
> sub logProcessing{
> my $line = '';
> my ($msg, $server);
> eval {
> local $SIG{ALRM} = sub { die "lesedauer" };
> alarm(1);
> $line = <$pipe_log>;
> alarm(0);
> };
I don't understand the point of this time out. If the timeout occurs,
you never complain about it or even detect it. You merely start another
call of the same thing that just timed out. If all you do upon a timeout
is restart the same thing, why bother timing out?
Anyway, if the alarm goes off after the next line is read from $pipe_log,
but before the "alarm(0)" gets executed, then you die out of the eval{} and
the line you just read from $pipe_log gets ignored. That could account for
your missing data!
>
> return if ($line !~ /::/);
Wouldn't it be better to die upon malformed data?
> ($msg, $server, $line) = split(/::/, $line);
>
> if(!exists $mshash{$server}){
> $mshash{$server} = $msg;
> }else{
> if($msg != $mshash{$server} +1){
> writeLog("Server $server: Missing message between $mshash{$server} and
> $msg");
I would add $line, if not $mshash2{$server}, to the logged info.
> }
> $mshash{$server} = $msg;
$mshash2{$server} = $line; # so prior line can also be logged
> }
> } # end of sub: logProcessing
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Thu, 05 Jan 2006 17:26:41 -0500
From: Marshall Dudley <mdudley@king-cart.com>
Subject: Line gives syntax error
Message-Id: <43BD9D21.82411722@king-cart.com>
I have a script that I wrote and debugged on a Windows machine, but it
fails on the UNIX machine. The line is:
$error = `echo $passcode | gpg $options $filename`;
The Windows machine brings up gpg, with the command line options of
$options and $filename, but the Unix machine gives me the following
error:
Syntax error: "|" unexpected.
Since I am printing out $error, and it is blank, the error appears to be
coming from Perl, although it does not abort or give a line number, so
maybe not. I have tried putting a "\" in front of the pipe, but get the
same result.
I initially thought it was the difference in operating systems, so I
tried entering:
echo abcdefg | gpg --batch --always-trust --passphrase-fd o cc.pgp
iat the command prompt in BASH, and it worked exactly like it was
suppose to, decrypting cc.pgp and writing the result to cc. This is
what it is getting passed in the perl program when the variables are
substituted for so it should have worked for Perl as well.
But maybe it is a difference in the Perl versions. The DOS machine is
running perl 5.005_3, and the Unix system is running 5.8.7
Anyone have any idea why one system is happy with this line, and the
other one is not and what I can use for a pipe symbol or change to make
it work?
Thanks,
Marshall
------------------------------
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 V10 Issue 8831
***************************************
