[22207] in Perl-Users-Digest
Perl-Users Digest, Issue: 4428 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Jan 19 11:05:41 2003
Date: Sun, 19 Jan 2003 08:05:06 -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 Sun, 19 Jan 2003 Volume: 10 Number: 4428
Today's topics:
Re: A Good Perl Developing Enviroment <mpapec@yahoo.com>
Re: Append a text at the top an existing file <jurgenex@hotmail.com>
Re: Data Form to Email Changes (Jonathan Tree)
Re: got me foxed <nwzmattXX@XXnetscape.net>
Re: got me foxed <david@morgmein.tk>
Re: got me foxed <david@morgmein.tk>
Re: How are named unary operators that take $_ created? (Peter J. Acklam)
Re: How can a SMTP mail be deleted from a Unix mailbox <not-a-real-address@usa.net>
Re: How to execute a perl script from within a perl scr <pne-news-20030119@newton.digitalspace.net>
Re: How to execute a perl script from within a perl scr <barbr-en@online.no>
Re: How to execute a perl script from within a perl scr <tassilo.parseval@post.rwth-aachen.de>
Re: How to execute a perl script from within a perl scr <flavell@mail.cern.ch>
Re: Inlining object methods via preprocessor for effici (Ben Morrow)
newsing as superuser (was Re: Why is order of REs impor (Tad McClellan)
Re: parse email from /var/spool/mail/username (Ben Morrow)
Re: parse email from /var/spool/mail/username <s.patterson@freeuk.com>
Re: parse email from /var/spool/mail/username <abigail@abigail.nl>
Re: Running a perl script as a windows 2000 service? (Ben Morrow)
Re: Running a perl script as a windows 2000 service? <bart.lateur@pandora.be>
Why is order of REs important? <root@siol.net>
Re: Why is order of REs important? (Tad McClellan)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 19 Jan 2003 11:51:31 +0100
From: Matija Papec <mpapec@yahoo.com>
Subject: Re: A Good Perl Developing Enviroment
Message-Id: <8o0l2vkm6rbl7odnqg2vmdjs5pjv2vhfds@4ax.com>
X-Ftn-To: A. Fuentes
"A. Fuentes" <alvarof2@hotmail.com> wrote:
>I have a newbie question:
>
>What would be a good Perl Developing Enviroment for
>managing and developing Perl projects?
>(Visual Developer Studio-like)
>
>Any suggestions will be appreciated.
http://www.crimsoneditor.com/
very fine editor.
--
Matija
------------------------------
Date: Sun, 19 Jan 2003 15:31:08 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Append a text at the top an existing file
Message-Id: <0xzW9.8391$e34.2107@nwrddc04.gnilink.net>
[Please do not post jeopardy style]
[Please do not blindly full-quote the article you are replying to]
Romuald Favre wrote:
> Actually, I checked first of all the PerlFAQ5 "How do I change one
> line in a file/delete a line in a file/insert a line in the middle of
> a file/append to the beginning of a file?" and I implemented a
> solution with its basic idea.
If you would have mentioned that ("Is there an easier way to ... then the
solution mentioned in the FAQ ...") then I'm sure you would have gotten much
friendlier responses. The way your original question came across was like a
jerk (sorry, no offense intended) who couldn't be bothered to read the FAQ.
And most people in this group react quite intense to those postings.
> But I was still wondering if it wasn't a similar and as easy solution
> as the appending at the end of a file (with the statement open
> (FILE,'>> file.txt')).
Well, think about it. To append bits to the end of a file you simply open
the file, seek to the end, and add stuff, allocating new sectors as needed.
No big deal.
Inserting bits into a file (no matter if at the beginning or somewhere in
the middle) means opening the file, and seeking to the target area
(beginning or somewhere in the middle).
But now you can't just write because it would overwrite the existing
content. Therefore you would have to shift the whole rest of the file by the
number of bytes you want to insert. And that means physically shifting the
bits on the harddrive(*). Only then you can write whatever you want to
write. And for the next 'print' shift the whole shebang again. And again.
And again. Not exactly a performance booster.
That's why inserting at the beginning or the middle of a file usually is not
supported by the operating system, and therefore neither by programming
languages.
(*): Yes, there are methods to reduce this overhead, like e.g. extensive
buffering or allocating new sectors for inserted text such that you don't
have to shift the whole file, just one sector at most. But still it's A LOT
more work than just appending text and it requires difficult housekeeping,
too.
jue
------------------------------
Date: 19 Jan 2003 07:54:24 -0800
From: takarov2003@yahoo.com (Jonathan Tree)
Subject: Re: Data Form to Email Changes
Message-Id: <c5129e0a.0301190754.7293521d@posting.google.com>
gbathgate2000@yahoo.com (Grayson Bathgate) wrote in message news:<e89f00b6.0301180527.175f140b@posting.google.com>...
> #2 send a resulting email response to the person who filled the
> form out in the first place.
>
You may find this to be a bad idea, as it could easily be abused for
harrassment or spamming.
------------------------------
Date: Sun, 19 Jan 2003 10:18:27 GMT
From: matt <nwzmattXX@XXnetscape.net>
Subject: Re: got me foxed
Message-Id: <3E2A5152.5030902@XXnetscape.net>
David Sparkmunster wrote:
>
> When I hit the submit button on the form, however, an error page comes
> up. If I close the error page and go back to the form page, it has
> done the write perfectly well.
>
The reason why you are getting the "Internal Server Error" is because
your script doesn't
print anything to STDOUT - which would go to the browser. For starters,
you need to print the http header: print "Content-type: text/HTML\n\n" .
After that, you need to print some HTML.
-- Matt
--
Remove the X's to reply directly.
------------------------------
Date: Sun, 19 Jan 2003 10:35:06 +0000
From: David Sparkmunster <david@morgmein.tk>
Subject: Re: got me foxed
Message-Id: <upvk2vkjb8u73pbol7bljqn894tg0ohmic@4ax.com>
Harald
thanks for your reply.
>I can't see where your script
>will output anything back to the server. A CGI is expected to return
>some data (a HTTP header and in most cases some HTML), and the user for
>sure wants to see a result for his action.
The .shttp page has several lists of names from text files on it apart
from the form. These are written to it by !--#exec.
The perl writes to these files which the user can then see the result
by hitting refresh. The important things are the text files, the
.shtml page is only a front end to alter them and check the result.
The pages are so that players in a big band can check in whether they
will be available for planned rehearsals and gigs in the future.
David
------------------------------------
David Thorpe
See my photo portfolio of royalty free pictures:
http://www.rebelartist.com/seller/dthorpe
See my theatre
The Surrey Stick Figure Theatre Of Death at:
http://www.c-cat.demon.co.uk/theatre/
------------------------------
Date: Sun, 19 Jan 2003 10:39:59 +0000
From: David Sparkmunster <david@morgmein.tk>
Subject: Re: got me foxed
Message-Id: <4tvk2vs2e7b4s5tdnd6sh9kvli1cpee4e4@4ax.com>
Tad
>> When I hit the submit button on the form, however, an error page comes
>> up.
>
>
>What does it say?
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.
Additionally, a 404 Not Found error was encountered while trying to
use an ErrorDocument to handle the request.
The perl checks out ok at the command line and does what I want - you
remark that the problem may be elsewhere and I feel you may be right
here.
My lack of knowledge gives me a problem with knowing what is a problem
with a web page itself and what is a problem with the cgi that is
making or contributing content for the page.
Complex but interesting.
Thanks for your help
David
------------------------------------
David Thorpe
See my photo portfolio of royalty free pictures:
http://www.rebelartist.com/seller/dthorpe
See my theatre
The Surrey Stick Figure Theatre Of Death at:
http://www.c-cat.demon.co.uk/theatre/
------------------------------
Date: Sun, 19 Jan 2003 13:36:24 +0100
From: pjacklam@online.no (Peter J. Acklam)
Subject: Re: How are named unary operators that take $_ created?
Message-Id: <of6diaev.fsf@online.no>
jl_post@hotmail.com (J. Romano) wrote:
> How do you create named unary operators that operate on $_ by
> default? [...]
I think you must use a prototype, like this:
sub ceil (;$) {
my $x = @_ ? $_[0] : $_;
my $ix = int $x;
($ix >= $x) ? $ix : $ix + 1;
}
Peter
--
#!/local/bin/perl5 -wp -*- mode: cperl; coding: iso-8859-1; -*-
# matlab comment stripper (strips comments from Matlab m-files)
s/^((?:(?:[])}\w.]'+|[^'%])+|'[^'\n]*(?:''[^'\n]*)*')*).*/$1/x;
------------------------------
Date: 19 Jan 2003 08:08:30 GMT
From: those who know me have no need of my name <not-a-real-address@usa.net>
Subject: Re: How can a SMTP mail be deleted from a Unix mailbox by a script?
Message-Id: <m1y95hvbz7.gnus@usa.net>
[fu-t set]
in comp.programming i read:
>The term "SMTP mail" that I've chosen specifies a message according to
>the standard "RFC 822" (http://ietf.org/rfc/rfc0822.txt). This format
>can be send over the communication protocol "SMTP" and some others.
rfc 2822 is the current standard. almost no system stores that format
unmodified, e.g., the unix mbox format prefixes it with a `from ' line and
prefixes lines that start with that string with a `>', and may retain the
smtp envelope as return-path and an x- headers. but even that's not
universal, e.g., solaris doesn't write a `from ' line instead it writes a
content-length header which is exactly correct.
>This request's subject is the deletion of messages in the file "mbox".
>1. Some programmes provide the prompt/command line as their
>programming interface.
that is a human interface. a programming interface is typically present in
the form of scripts manipulating variables and calling functions.
libraries are available that can manipulate various mailboxes formats,
e.g., c-client from the university of washington.
>I encounter the difficulty to scroll through all exististing messages
>by a command to find the right number for the message that should be
>deleted. I am looking for an efficient algorithm.
there is no particularly efficient algorithm, you must read the entire
file, collecting all the sensible headers (e.g., from, subject) as you
progress. to make future manipulation more efficient you can record the
position within the file of each message.
>3. A method for the deletion seems to be missing. I come to a
>fundamental programming problem now.
>How can a piece be cut out from the file "mbox" that can be huge in
>size and that is accessed rapidly and perhaps without breaks while new
>messages are appended to the file end?
nothing can be done until you have your system's locking mechanism
implemented.
let me reiterate that: you cannot manipulate an mbox-style mailbox without
having obtained a proper lock. and there is no universal lock, which
always works, each system has it's own notion of what is appropriate. once
you have the lock no other changes will be allowed, i.e., no new messages
will be added by the lda and no other processes should be manipulating it.
this is one of the reasons that other mailbox formats (e.g., mh, maildir
and mbx) have been created.
once the mailbox is locked you can use a shuffle loop (seek/read/seek/write)
to copy the portion of the mailbox that follows the deleted message to it's
new position (over the top of the deleted message), truncating the file to
the new length. if there are multiple messages to be deleted then you can
optimize this by doing all the messages in a single pass.
now let me back-pedal some: if you are only deleting messages then since
you will only be moving messages `up' in the file you can risk doing so
without locking the file, but you must take great care to: re-validate the
seek positions if you saved them during the initial scan and abort if there
is any change (because another copy of your program is running), and create
a dummy message at the end of the file that *exactly* consumes the space
you eliminate and check for a size increase before you change the file
length. if the file increased in size then a new message or messages have
arrived which you'll have to shuffle into place (i.e., repeat these steps).
>(The programme "mailx" has got a built-in solution.
>3.1 I do not know yet how to put the ends of the gap together again.
perhaps scripting interaction with mailx is what you want to do then.
>3.2 The file can always be written (without the deleted contents) to a
>new version. The updated version replaces the old one. Is this
>applicable if you think about speed?
it can be acceptable, on good systems. but if the mailbox is huge it's
better to use a different format (mh, maildir or mbx). in fact i would be
tempted to do it all via the imap, provided such a service can be enabled.
--
bringing you boring signatures for 17 years
------------------------------
Date: Sun, 19 Jan 2003 16:53:37 +0100
From: Philip Newton <pne-news-20030119@newton.digitalspace.net>
Subject: Re: How to execute a perl script from within a perl script and return info
Message-Id: <1eil2vsqb7mdsuqkpr692sshvf3sbrg2kn@4ax.com>
On Sun, 19 Jan 2003 13:11:16 +0100, "Alan J. Flavell"
<flavell@mail.cern.ch> wrote:
> Just as a side comment to this: as I understand it, the German (de.*)
> hierarchy have had a reasonably-active ...perl.cgi group for some
> time, but are just voting to abolish their WWW CGI group on the basis
> that it has fallen into disuse.
>
> This is not meant as any kind of proposal for the comp.* hierarchy,
> and certainly not as a troll; just a comment on the situation as I
> understand it to be. It would be interesting to hear how it looks to
> those who are active on the de.* hierarchies,
I thought that was rather unfortunate when I saw it.
I can understand (I think) the rationale for creating
de.comp.lang.perl.cgi, but I still think there should be a "just CGI"
newsgroup.
Cheers,
Philip
--
Philip Newton <nospam.newton@gmx.li>
That really is my address; no need to remove anything to reply.
If you're not part of the solution, you're part of the precipitate.
------------------------------
Date: Sun, 19 Jan 2003 12:05:55 +0100
From: Kåre Olai Lindbach <barbr-en@online.no>
Subject: Re: How to execute a perl script from within a perl script and return info
Message-Id: <6a1l2vchcbsmhue554h48023nrmi3boire@4ax.com>
On Sat, 18 Jan 2003 08:24:06 -0600, tadmc@augustmail.com (Tad
McClellan) wrote:
>Anders Torvill Bjorvand <torvill@trolldata.no> wrote:
>
>> But how can I get the printed output from b.cgi into a variable $content in
>> a.cgi?
>>
>> Can I simply do:
>> $content = system("/home/www/myserver/mydir/b.cgi");
>
>have you heard of the really great perl documentation?
>
>If you read the documentation for the function that you are using
>there, it will tell you how to do what you have asked.
>
>Please don't ask others to read the docs to you.
>
> perldoc -f system
>
> This is *not* what you want to use to capture the output
> from a command, for that you should use merely ...
Just for info to the OP: We also have a nice newsgroup in Norwegian
called "no.it.programmering.perl" with so low traffic that we allow
(tolerate) both FAQ-questions and CGI/HTML-related stuff ;-)
--
mvh/Regards
Kåre Olai Lindbach
------------------------------
Date: 19 Jan 2003 15:47:36 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@post.rwth-aachen.de>
Subject: Re: How to execute a perl script from within a perl script and return info
Message-Id: <b0ehao$ck3$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Alan J. Flavell:
> On Jan 19, Kåre Olai Lindbach inscribed on the eternal scroll:
>
>> Just for info to the OP: We also have a nice newsgroup in Norwegian
>> called "no.it.programmering.perl" with so low traffic that we allow
>> (tolerate) both FAQ-questions and CGI/HTML-related stuff ;-)
>
> Just as a side comment to this: as I understand it, the German (de.*)
> hierarchy have had a reasonably-active ...perl.cgi group for some
> time, but are just voting to abolish their WWW CGI group on the basis
> that it has fallen into disuse.
I haven't observed any disuse within the past week. On the contrary,
at least I have the impression that dclp.cgi produces a similar amount
of traffic as dclp in these days.
> This is not meant as any kind of proposal for the comp.* hierarchy,
> and certainly not as a troll; just a comment on the situation as I
> understand it to be. It would be interesting to hear how it looks to
> those who are active on the de.* hierarchies,
From my personal standpoint, it looks quite good. dclpm receives far
less CGI-related postings than this group which makes it a pleasant spot
overall. I'd even go as far as saying that a clp.cgi would be a benefit
to this group, too.
Tassilo
--
$_=q!",}])(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus;})(rekcah{lrePbus;})(lreP{rehtonabus;})(rehtona{tsuJbus!;
$_=reverse;s/sub/(reverse"bus").chr(32)/xge;tr~\n~~d;eval;
------------------------------
Date: Sun, 19 Jan 2003 13:11:16 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: How to execute a perl script from within a perl script and return info
Message-Id: <Pine.LNX.4.40.0301191259380.20094-100000@lxplus069.cern.ch>
On Jan 19, Kåre Olai Lindbach inscribed on the eternal scroll:
> Just for info to the OP: We also have a nice newsgroup in Norwegian
> called "no.it.programmering.perl" with so low traffic that we allow
> (tolerate) both FAQ-questions and CGI/HTML-related stuff ;-)
Just as a side comment to this: as I understand it, the German (de.*)
hierarchy have had a reasonably-active ...perl.cgi group for some
time, but are just voting to abolish their WWW CGI group on the basis
that it has fallen into disuse.
This is not meant as any kind of proposal for the comp.* hierarchy,
and certainly not as a troll; just a comment on the situation as I
understand it to be. It would be interesting to hear how it looks to
those who are active on the de.* hierarchies,
------------------------------
Date: Sun, 19 Jan 2003 09:08:01 +0000 (UTC)
From: mauzo@mimosa.csv.warwick.ac.uk (Ben Morrow)
Subject: Re: Inlining object methods via preprocessor for efficiency (!?)
Message-Id: <b0dpth$eid$1@wisteria.csv.warwick.ac.uk>
richw@richw.org (Rich Wales) wrote:
>I wrote an object-oriented Perl program some time ago which needed
>to run as fast as possible.
Hmm, bad plan. OO is slow in Perl, as inheritance is computed at compile time.
>One speed problem I foresaw involved object methods. To give one
>example, I had a class called "Ch", and one of the data elements
>in a "Ch" was called "extra" (don't ask what it means, it doesn't
>really matter here). The "extra" element got set up near the
>start of the program and was thereafter supposed to be treated
>as read-only.
>
>The obvious Perl thing to do would have been to write a method
>called "extra", something like this:
>
> sub extra { my this = shift; this->{extra} }
>
>and then write things like some_ch->extra() all through my
>code. But the problem I saw with that approach was that I would
>have been incurring the overhead of calling a function each and
>every time I wanted to access the "extra" element of a "Ch" object.
Indeed of calling a method, which is rather worse.
>So, instead, I tried setting up my original Perl source to be run
>through the "cpp" preprocessor (via a custom filter script that
>prevented ordinary comment lines from being mangled by "cpp";
>again, please don't worry or ask about the gory details of this
>right now). I did this preprocessing only once (via "make") and
>saved the result to be run as often as needed later on.
>
>One of the lines in my header file looked something like this:
>
> #define chExtra(c) do { c->{extra} }
>
>which allowed me to write things like chExtra(some_ch) in my
>code, and they would be expanded inline without function calls.
>(The "do" block around the macro was to prevent it from being
>used as an lvalue, since I wanted the value to be read-only.)
YEEUCH! What on earth is wrong with using c->{extra} throughout your code,
since the cpp doesn't do any inheritance (which is the usual reason for
wrapping attributes in methods). If you _need_ to prevent it from being an
lvalue, you could try using Hash::Util, which I think will let you lock a value
to be constant.
However: did you profile your code and find that these attribute accesses were
actually causing major slowdown? Premature optimization is the root of all
evil.
Ben
------------------------------
Date: Sun, 19 Jan 2003 08:54:35 -0600
From: tadmc@augustmail.com (Tad McClellan)
Subject: newsing as superuser (was Re: Why is order of REs important?)
Message-Id: <slrnb2lf1b.i00.tadmc@magna.augustmail.com>
Andrej Hocevar <root@siol.net> wrote:
> From: Andrej Hocevar <root@siol.net>
^^^^^
^^^^^
Please, oh please, tell me that you are not really accessing
news from the superuser account.
If so, then you aren't really ready to have the root password yet.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 19 Jan 2003 08:56:38 +0000 (UTC)
From: mauzo@mimosa.csv.warwick.ac.uk (Ben Morrow)
Subject: Re: parse email from /var/spool/mail/username
Message-Id: <b0dp86$ecp$1@wisteria.csv.warwick.ac.uk>
istink <istink@real.bad.com> wrote:
>Anyone know what separates each message in the /var/spool/mail/username
>file?
This is not a Perl question.
Have a look at it and see. I believe it's system-dependant.
You might also want to try man mbox.
Ben
------------------------------
Date: 19 Jan 2003 11:36:29 GMT
From: Stephen Patterson <s.patterson@freeuk.com>
Subject: Re: parse email from /var/spool/mail/username
Message-Id: <slrnb2l3dv.2pf.s.patterson@bloodnok.localdomain>
On Sat, 18 Jan 2003 22:12:24 -0500, istink wrote:
> Anyone know what separates each message in the /var/spool/mail/username
> file?
It should be an mbox file, so Mail::Folder::Mbox or Mail::Box::Mbox
--
Stephen Patterson http://www.lexx.uklinux.net http://patter.mine.nu
steve@SPAM.lexx.uklinux.net remove SPAM to reply
Linux Counter No: 142831 GPG Public key: 252B8B37
Last one down the pub's an MCSE
------------------------------
Date: 19 Jan 2003 13:27:15 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: parse email from /var/spool/mail/username
Message-Id: <slrnb2la35.rc2.abigail@alexandra.abigail.nl>
istink (istink@real.bad.com) wrote on MMMCDXXVIII September MCMXCIII in
<URL:news:3E2A1798.41901D39@real.bad.com>:
?? Anyone know what separates each message in the /var/spool/mail/username
?? file?
It depends. It's not the same on each system. One common way is:
"\nFrom <address>". But not every system works this way.
And it doesn't have anything to do with Perl. You're better off asking
this question in one of the newsgroups dealing with mail.
Abigail
--
perl -wle'print"Êõóô áîïôèåò Ðåòì Èáãëåò"^"\x80"x24'
------------------------------
Date: Sun, 19 Jan 2003 08:54:37 +0000 (UTC)
From: mauzo@mimosa.csv.warwick.ac.uk (Ben Morrow)
Subject: Re: Running a perl script as a windows 2000 service?
Message-Id: <b0dp4d$eap$1@wisteria.csv.warwick.ac.uk>
"MG" <me@home.com> wrote:
>not sure if this would be a windows post or a perl post but here goes:
>
>I have some perl scripts that I want to initialize when my webserver starts
>up. Unfortunately, Windows isn't like linux and I can't just add
>./myscript.pl to a runlevel to make it run at startup. I have to manually
>run it and unfortunatley I am stuck with a DOS box on my screen (is there
>anything like the unix `&' postfix that will run it in the background?).
>With my current method, if the computer reboots (as is common on windows
>machines) and I'm not around the script will not run until I log in. It
>also will not respawn if it crashed, like with a service. Hopefully someone
>out there might have some clues as to how to do this (or if theres a utility
>to do it for me!). Thanks.
Win32::Daemon
Ben
------------------------------
Date: Sun, 19 Jan 2003 08:59:30 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: Running a perl script as a windows 2000 service?
Message-Id: <supk2vgpn3mek3ckmdcabo7kdbmnqmdvcr@4ax.com>
The advice John Fraser gave you (startup folder or registry entry for
the automatic startup, wperl to hide the console) would be the first I
thought of. However, there are also a few entries on running perl
scripts as services in Activestate's FAQ, for NT and for Win2k, with
perhaps a better approach:
How do I run a Perl script as a Windows NT Service?
How do I run a Perl script as a Windows 2000 Service?
<http://aspn.activestate.com//ASPN/Reference/Products/ActivePerl/faq/Windows/ActivePerl-Winfaq4.html#How_do_I_run_a_Perl_script_as>
--
Bart.
------------------------------
Date: Sun, 19 Jan 2003 11:39:55 +0000 (UTC)
From: Andrej Hocevar <root@siol.net>
Subject: Why is order of REs important?
Message-Id: <slrnb2l3ka.2gn.root@sonet.utopija.linux>
Hello.
I have a little problem with a program I've pasted here. It seems
that the order in the configuration file is important: in this
example, both rules should match, but instead only one does with
inapropriate order. Why is this?
I appologize for the useless lines here, they're just an artefact,
since this is only a test script.
If the rule #3 precedes rule #2, then both match, otherwise they
don't. This shouldn't be, right?
thanks,
andrej
--------------------------------------------------------------------
#!/usr/bin/perl
$temp = "/tmp/mofo.tmp.TEST";
$outm = "/tmp/mofo.tmp.new.TEST";
$conf_f = "mofoconf";
# counters
$k = 1;
$l = 1;
$z = 0;
$i = 0;
$ii = 0;
$j = 0;
$jj =0;
$filters = 0;
$accuracy = 0;
@match = "ZADETEK";
# ---------------------------------------------------------------- #
open(TEMP, "> $temp") or die;
open(CONF, "$conf_f") or die;
open(CONF, "$conf_f") or die;
while (<CONF>) {
next if /^$|^\#/;
chomp;
$filters = 1 if (/^FILTERS/);
if ($filters == 0) {
if ($prev =~ /^RULE/) {
$i++;
$ii = 0;
}
$rule[$i][$ii] = $_;
$ii++;
$prev = $_;
}
while (<>) {
print TEMP $_;
}
close(TEMP);
open(TEMP, $temp);
{
$/ = "";
$header = <TEMP>;
undef $/;
}
close(TEMP);
@header_lines = split /\n(?!\s)/, $header;
foreach (@header_lines) {
if (/^From /) {
s/^/0From: /;
}
s/:/_$z:/;
$z++;
($label, $value) = split /:\s*/, $_, 2;
$header_fields{$label} = $value;
}
# ------------------------------------------------------------------- #
# subroutines
sub track_spam($) {
@all_hfields = keys %header_fields;
$search_hfields = $rule[${_[0]}][0];
$action = $rule[${_[0]}][1];
$search_hcontent = $rule[${_[0]}][2];
$search_id = $rule[${_[0]}][3];
$ok = $rule[${_[0]}][4];
@r = ();
@r = grep(/$search_hfields/ig, @all_hfields);
foreach (@r) {
if ($header_fields{$_} =~ /$search_hcontent/gsi) {
push @match, "\n{[$search_hfields][$search_id]\n [$header_fields{$_}]}";
}
}
}
# from the configuration file
while ($k <= $i) {
print "$k :: id $rule[$k][3] \n";
track_spam($k);
$k++
}
########################################################
print "\n--------------\n@match \n";
--------------------------------------------------------------------
here's the relevant part of the config:
RULE: 2
^to
matches
pop\.siol\.net
pop.siol.net
X
RULE: 3
^to
matches
\"\@
prejemnik z narekovaji
X
--------------------------------------------------------------------
this is a relevant part of the text I'm using:
To: <"lucky customers"@pop.siol.net> <ah@siol.net>
---------------------------------------------------------------------
--
echo ${girl_name} > /etc/dumpdates
------------------------------
Date: Sun, 19 Jan 2003 09:34:21 -0600
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: Why is order of REs important?
Message-Id: <slrnb2lhbt.i00.tadmc@magna.augustmail.com>
Andrej Hocevar <root@siol.net> wrote:
> I have a little problem with a program I've pasted here.
Yes you do. It does not compile.
If you really did paste it, then you made an error in the pasting,
or your original program does not even execute.
So, we don't have access to your real code, since I assume that
your real code _will_ execute.
Not much sense in troubleshooting code that does not really exist.
> It seems
> that the order in the configuration file is important: in this
> example, both rules should match, but instead only one does with
> inapropriate order. Why is this?
I can't help you with that for several reasons, the primary one
being that I do not know what logic you've coded up, because I
don't know where you meant to put the missing curly brace.
> I appologize for the useless lines here, they're just an artefact,
> since this is only a test script.
If you had made a short (less than 20-30 lines) and *complete* program
that illustrates the problem you are having, then you wouldn't need
to apologize, plus we would be able to give you real help.
Debugging 100 lines of code that doesn't run, with no attempt at
getting automated help, and coding in a strange C-like style is
not something that many folks are going to volunteer for.
You have made it too hard for me to give you directly applicable
help, but I'll point out some other things anyway.
> If the rule #3 precedes rule #2, then both match, otherwise they
> don't. This shouldn't be, right?
I dunno. I cannot make enough sense of your code to figure out
what it is supposed to do. Sorry.
> #!/usr/bin/perl
Ask perl to help you
You can ask perl itself to help you find common programming mistakes
by doing two things: enable warnings (perldoc warnings) and enable
"strict"ures (perldoc strict).
So your program should start like this:
#!/usr/bin/perl
use strict;
use warnings;
> open(CONF, "$conf_f") or die;
^ ^
^ ^ a useless use of double quotes
You should arrange to give a diag message that will help you
discover what it is that went wrong, should the open() ever fail:
open(CONF, $conf_f) or die "could not open '$conf_f' $!";
^^
^^
> while (<CONF>) {
> next if /^$|^\#/;
> chomp;
> $filters = 1 if (/^FILTERS/);
>
> if ($filters == 0) {
> if ($prev =~ /^RULE/) {
> $i++;
> $ii = 0;
> }
> $rule[$i][$ii] = $_;
> $ii++;
> $prev = $_;
> }
You are missing a closing curly brace there somewhere...
You don't need the $ii variable. If you just did:
push @{ $rule[$i] }, $_;
instead of
$rule[$i][$ii] = $_;
then perl would maintain the index for you.
> while (<>) {
> print TEMP $_;
> }
> close(TEMP);
>
> open(TEMP, $temp);
> {
> $/ = "";
"para mode" is now enabled *for every read in your program*, not
just the <TEMP> reading you have below. You should localize
changes to global variables:
local $/ = "";
> $header = <TEMP>;
> undef $/;
Now you have "slurp mode" enabled for every subsequent read. If you
local()ized your change as suggested above, the value of $/
would revert to its previous value automatically when you
leave the scope below.
Or at least set $/ to its normal default value: $/ = "\n";
> }
> close(TEMP);
What is all that writing and reading for?
You do not need a temp file.
If you want all the headers in $header, you can just put them there
in the first place:
while (<>) {
last if /^\s*$/; # empty line marks end of headers
$header .= $_;
}
> if (/^From /) {
> s/^/0From: /;
> }
There is no need to match before you substitute:
s/^From /0From: /;
will do the same thing as your whole if there.
> sub track_spam($) {
^^^
^^^
You very likey do NOT want to be using prototypes, at least until
you get more knowledgeable about Perl's fundamentals.
> $search_hfields = $rule[${_[0]}][0];
^ ^
^ ^ a useless use of curly braces
$search_hfields = $rule[$_[0]][0]; # does the same thing
> @r = ();
> @r = grep(/$search_hfields/ig, @all_hfields);
The @r = () is completely useless, since you are going to stomp
over any values that were in @r on the next line anyway.
If you want a mail filter for use in the real world, I'd suggest
finding an already written one instead of trying to build your own.
Consider using SpamAssassin or the Mail::Audit module to help you.
You might also want to have a look at the Posting Guidelines that
are posted here weekly. Following the suggestions there will
greatly increase your chances of getting help with your Perl problems.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
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 4428
***************************************
