[23172] in Perl-Users-Digest
Perl-Users Digest, Issue: 5393 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Aug 20 00:05:54 2003
Date: Tue, 19 Aug 2003 21:05:10 -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 Tue, 19 Aug 2003 Volume: 10 Number: 5393
Today's topics:
Re: comp.lang.perl.open.discussion rfc in alt.config <scripts_you_know_the_drill_@hudsonscripting.com>
Re: comp.lang.perl.open.discussion rfc in alt.config <scripts_you_know_the_drill_@hudsonscripting.com>
Re: comp.lang.perl.open.discussion rfc in alt.config <scripts_you_know_the_drill_@hudsonscripting.com>
Re: comp.lang.perl.open.discussion rfc in alt.config <scripts_you_know_the_drill_@hudsonscripting.com>
dogma....re: modules <scripts_you_know_the_drill_@hudsonscripting.com>
Re: dogma....re: modules <tony_curtis32@yahoo.com>
Re: dogma....re: modules <bwalton@rochester.rr.com>
Re: dogma....re: modules <scripts_you_know_the_drill_@hudsonscripting.com>
Re: dogma....re: modules <scripts_you_know_the_drill_@hudsonscripting.com>
Re: dogma....re: modules <scripts_you_know_the_drill_@hudsonscripting.com>
Re: dogma....re: modules (Randal L. Schwartz)
Re: dogma....re: modules (Randal L. Schwartz)
Re: dogma....re: modules <tony_curtis32@yahoo.com>
Re: dogma....re: modules <scripts_you_know_the_drill_@hudsonscripting.com>
Re: dogma....re: modules <scripts_you_know_the_drill_@hudsonscripting.com>
Re: file upload in cgi <scripts_you_know_the_drill_@hudsonscripting.com>
Re: file upload in cgi <scripts_you_know_the_drill_@hudsonscripting.com>
Re: Low-level way of fetching UDP datagram as a unit (James Willmore)
Re: Order of evaluation of expressions <ben.goldberg@hotpop.com>
Re: Order of evaluation of expressions <REMOVEsdnCAPS@comcast.net>
Perl help <duster@duster.com>
Re: Perl help <dha@panix.com>
Perl script vs. fetchmail & procmail <Shawn@Linurati.net>
Re: plouk zombie plouk zombie <scripts_you_know_the_drill_@hudsonscripting.com>
Re: Quick removal of the begging of a file? <ben.goldberg@hotpop.com>
Re: Regex - assign to new variable and replace in one l <bwalton@rochester.rr.com>
Re: Regex - assign to new variable and replace in one l <usenet@dwall.fastmail.fm>
Re: Regular Expression Question <simon@unisolve.com.au>
Re: Why a sudden taint error with change in ISP server' (Bill)
Re: <bwalton@rochester.rr.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 19 Aug 2003 21:16:19 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: comp.lang.perl.open.discussion rfc in alt.config
Message-Id: <mft5kvcmjajjviqss7ke947eq8fvv7p40e@4ax.com>
>>why? alt.config is where you create newsgroups...right?
>
>Only for alt groups.
imagine my surprise ;-)
------------------------------
Date: Tue, 19 Aug 2003 22:34:33 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: comp.lang.perl.open.discussion rfc in alt.config
Message-Id: <6r16kv49rmkkhf1m9v3o1868nrmrcabrmc@4ax.com>
>hudson> why? alt.config is where you create newsgroups...right?
>
>Newsgroups in alt.*, but not comp.*. A little research would have
>shown the contrary. A *little* research.
well...with a little trial and error, I now understand that alt.config
won't help in creating a comp newsgroup...my *little* research here
taught me as much.
>You know, you seem to consistently learn *just enough* to be
>*dangerous*, but not enough to know as much as you think you know.
>Perhaps this is a clue. Perhaps you'll take this as feedback. Maybe
>instead you'll just write me off, because it's not what you want to
>hear.
what's your clue/feedback? not to try and learn new things? Lord knows
I will never, ever try and create a comp newsgroup on alt.config ;-)
------------------------------
Date: Tue, 19 Aug 2003 22:44:05 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: comp.lang.perl.open.discussion rfc in alt.config
Message-Id: <cc26kvcntrco6g624d8qbb40cbotj02hcn@4ax.com>
>One last thing - why did you answer my one post with two? I note that
>the one commenting on the difference between alt groups and others was
>perfectly reasonable, while this one is argumentative and insulting.
Hey David, I am sorry if I answered in an argumentative tone here. To
tell you the truth, I started too many threads and too many people
replied and so I think it is all too much ;-)
I am just trying to read back and reply as I can. A lot of people
wrote things that I think are reasonable and I appreciate all the
input.
Anyway, accept my apologies if I lashed out by mistake. I've never
been flamed before.
------------------------------
Date: Tue, 19 Aug 2003 22:53:14 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: comp.lang.perl.open.discussion rfc in alt.config
Message-Id: <0236kvoqtku7d14lmr15ujqcoav21p26il@4ax.com>
>Maybe, but judging from your writing you don't have enough knowledge to find
>that out. And since you're acting like troll and flooding clpm with offtopic
>and insulting posts others can only send you to abuse@supernews.com(or, come
>to your home, visit your dog/gold fish, relatives and such :>)
this isn't a public forum? go ahead and send to abuse@supernews.com
that I was posting to a public forum....
and all you perl hackers can have my dog/gold fish...send me your
address and I will fedex them to you to do what you please....hehe
(well, I don't have any dogs/gold fish, but I'm really not concerned)
------------------------------
Date: Tue, 19 Aug 2003 22:11:17 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: dogma....re: modules
Message-Id: <9h06kv0d16r2vuqscct4perakmuer2c7t3@4ax.com>
Well...having had a bit of experience with this group, and looking
through some google searches I am a little shocked to see this same
attitude about modules from as far back as 1998....
I see the same closed minded "it is too hard, so trust the module"
attitude. The thread that caught my eye was about deleting a
directory...but just the same attitude overall.
------------------------------
Date: Tue, 19 Aug 2003 21:46:54 -0500
From: Tony Curtis <tony_curtis32@yahoo.com>
Subject: Re: dogma....re: modules
Message-Id: <87he4d59lt.fsf@limey.hpcc.uh.edu>
>> On Tue, 19 Aug 2003 22:11:17 -0700,
>> hudson <scripts_you_know_the_drill_@hudsonscripting.com> said:
> Well...having had a bit of experience with this group,
> and looking through some google searches I am a little
> shocked to see this same attitude about modules from as
> far back as 1998....
I wonder why that is...
Would you say the same thing in a surgeons' newsgroup
where everyone was telling you for years that performing
brain surgery after 6 pints might not be a good idea? Or
would you say "oh, you're all sho closhed minded, I can do
it fine with thish chishel"?
(OK, brain surgeon might not be a good example here for
closed minds :-)
> I see the same closed minded "it is too hard, so trust
> the module" attitude. The thread that caught my eye was
> about deleting a directory...but just the same attitude
> overall.
It's the right way to do things. The ability to abstract
processes and see underlying regular structures requires
experience in programming. It's easy to see the
individual simple cases straight off the bat. What you
don't see immediately are the less obvious cases that will
come back to haunt you sooner than you think (Sod's Law).
(Try posting your design for a perpetual motion machine to
sci.physics and see what happens :-)
hth
t
------------------------------
Date: Wed, 20 Aug 2003 02:54:21 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re: dogma....re: modules
Message-Id: <3F42E2B6.40107@rochester.rr.com>
hudson wrote:
> Well...having had a bit of experience with this group, and looking
> through some google searches I am a little shocked to see this same
> attitude about modules from as far back as 1998....
>
> I see the same closed minded "it is too hard, so trust the module"
> attitude. The thread that caught my eye was about deleting a
> directory...but just the same attitude overall.
>
Well, knock yourself out rewriting all 5098 modules currently on CPAN if
you wish. I personally find the way to productivity is to use
peer-reviewed widely used and maintained reusable code -- in other
words, modules. I can access databases, transfer files, build GUI's,
generate data plots in CGI, grab web pages, etc etc, all without
understanding or even knowing what is inside the dozens of modules that
all work together to make that stuff happen. And it all works 100%. If
I had to write or even just examine all the lines of all that code, I
would die an old man before I got my first program working. Yet I can
do very significant projects in just a few hours with only dozens of
lines of program to write. It is a tremendous boost to one's
productivity to be able to re-use the code done by others. You won't
pay the bills by ignoring modules.
I'll give you a challenge: Rewrite DBI, and let me know when you're
done and it passes its test suite. Then I'll let you know how many
full-blown database apps I could have coded in the meantime.
--
Bob Walton
------------------------------
Date: Tue, 19 Aug 2003 23:03:00 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: dogma....re: modules
Message-Id: <2d36kvo1t3juvr2n4q824lrr3milcmp2f6@4ax.com>
Hey Tony, thanks for the reply.
>> Well...having had a bit of experience with this group,
>> and looking through some google searches I am a little
>> shocked to see this same attitude about modules from as
>> far back as 1998....
>
>I wonder why that is...
>
>Would you say the same thing in a surgeons' newsgroup
>where everyone was telling you for years that performing
>brain surgery after 6 pints might not be a good idea? Or
>would you say "oh, you're all sho closhed minded, I can do
>it fine with thish chishel"?
Well...I am told not to do SOAP by myself, not to do CGI by myself,
not to delete a directory by myself, etc, etc....makes you kind of
wonder.........
>It's the right way to do things. The ability to abstract
>processes and see underlying regular structures requires
>experience in programming. It's easy to see the
>individual simple cases straight off the bat. What you
>don't see immediately are the less obvious cases that will
>come back to haunt you sooner than you think (Sod's Law).
words like "it's the right way to do it" are groupspeak. They are
meaningless. Not to be rude or anything, but I think what I saw in
CGI.pm wasn't too much, although no one has posted up a reply yet. I
am sure if I look in the file pm that deletes a directory, I will see
nothing too much either.
And this groupspeak is the same when people say "we need to have the
right example for when people search google". All mythology to me.
Again, thank you for your reply. I just see things a bit differently
from people around here, but I am open to discussion.
------------------------------
Date: Tue, 19 Aug 2003 23:07:07 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: dogma....re: modules
Message-Id: <or36kvk3g581lds4ful2s5dcpi2seevcrv@4ax.com>
>Well, knock yourself out rewriting all 5098 modules currently on CPAN if
>you wish. I personally find the way to productivity is to use
>peer-reviewed widely used and maintained reusable code -- in other
>words, modules. I can access databases, transfer files, build GUI's,
>generate data plots in CGI, grab web pages, etc etc, all without
>understanding or even knowing what is inside the dozens of modules that
>all work together to make that stuff happen. And it all works 100%. If
>I had to write or even just examine all the lines of all that code, I
>would die an old man before I got my first program working. Yet I can
>do very significant projects in just a few hours with only dozens of
>lines of program to write. It is a tremendous boost to one's
>productivity to be able to re-use the code done by others. You won't
>pay the bills by ignoring modules.
>
>I'll give you a challenge: Rewrite DBI, and let me know when you're
>done and it passes its test suite. Then I'll let you know how many
>full-blown database apps I could have coded in the meantime.
that's not my point Bob, and you know it. My point is I am smart
enough to write stuff for CGI or SOAP or delete a simple directory and
people in this newsgroup have this kneejerk attitude that "no...you
can't do that by yourself" and I think that's wrong.
------------------------------
Date: Tue, 19 Aug 2003 23:19:20 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: dogma....re: modules
Message-Id: <bl46kvg0om99o9m1ukf72o9v2ea01cmu6s@4ax.com>
On Tue, 19 Aug 2003 23:03:00 -0700, hudson
<scripts_you_know_the_drill_@hudsonscripting.com> wrote:
>Well...I am told not to do SOAP by myself, not to do CGI by myself,
>not to delete a directory by myself, etc, etc....makes you kind of
>wonder.........
I mean, come on...I can delete a directory as follows:
`rm -r $directory`
no big deal...I need a module for that?
------------------------------
Date: Wed, 20 Aug 2003 03:33:44 GMT
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: dogma....re: modules
Message-Id: <bc5e43591a719572d028414609168622@news.teranews.com>
>>>>> "hudson" == hudson <scripts_you_know_the_drill_@hudsonscripting.com> writes:
hudson> I mean, come on...I can delete a directory as follows:
hudson> `rm -r $directory`
Unless $directory contains whitespace, or a semicolon, asterisk, less
than, greater than, bar, bracket/brace (either kind), pound, up-arrow,
ampersand, parenthesis, backslash, single quote, double quote,
question mark, and did I leave anything out?
And then you have to have the *right* rm in your path, hoping it hasn't
been trojaned.
And you probably have to be on Unix.
Truly, what a win (he says sarcastically) over using the *proper* tool:
use File::Path;
rmtree($directory);
And guess what... NONE of those problems now apply. Nor does it
even fork, so it'll be faster in the long run over using "rm".
You know, hudson, please keep it up. You're proving our point
every time you open your mouth. Thanks for helping!
print "Just another Perl hacker,"
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: Wed, 20 Aug 2003 03:33:46 GMT
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: dogma....re: modules
Message-Id: <75467b1859e0aca9441c67aa7fe45b67@news.teranews.com>
>>>>> "hudson" == hudson <scripts_you_know_the_drill_@hudsonscripting.com> writes:
hudson> that's not my point Bob, and you know it. My point is I am smart
hudson> enough to write stuff for CGI or SOAP or delete a simple directory
No, you *think* you're smart enough to delete a simple directory. See
my other post in this thread.
And that's also what I said before. You are not as smart as you think
you are, and people keep pointing it out here. And every time you
open your mouth, you remove any doubt. :)
hudson> and
hudson> people in this newsgroup have this kneejerk attitude that "no...you
hudson> can't do that by yourself" and I think that's wrong.
Go ahead. Think it's wrong. See if it actually helps you to think
that, at the end of the day.
Whereas, the professional programmers in this group are saying
something else, and getting more robust, better code done at the end
of the day than you'll ever hope to do in a week.
Learn. Learn. Pay attention.
print "Just another Perl hacker,"
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: Tue, 19 Aug 2003 22:33:32 -0500
From: Tony Curtis <tony_curtis32@yahoo.com>
Subject: Re: dogma....re: modules
Message-Id: <87d6f157g3.fsf@limey.hpcc.uh.edu>
>> On Tue, 19 Aug 2003 23:03:00 -0700,
>> hudson <scripts_you_know_the_drill_@hudsonscripting.com> said:
> anything, but I think what I saw in CGI.pm wasn't too
> much.
You're either a troll or you really have no idea what
you're going on about.
There's lots to learn here (for everyone). Understanding
why professionals program in this way (modules,
abstraction, re-use) is what you need to start with.
Do you perhaps have a conceptual barrier to using
objects/classes etc? (Before you jump, this is not meant
to belittle, everyone has to start programming sometime,
except Larry Wall of course :-)
------------------------------
Date: Tue, 19 Aug 2003 23:50:45 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: dogma....re: modules
Message-Id: <nd66kvos543d83otf0cercavctpoisupoe@4ax.com>
On Wed, 20 Aug 2003 03:33:44 GMT, merlyn@stonehenge.com (Randal L.
Schwartz) wrote:
>You know, hudson, please keep it up. You're proving our point
>every time you open your mouth. Thanks for helping!
bah...the whole point is to hack, hack, hack until you get the thing
to do what you want...don't you agree?
get it working and then understand what the hell you did...that's the
learning process ;-)
but....it's all fun and games (for me, at least) so thank you merlyn
for your reply.
------------------------------
Date: Tue, 19 Aug 2003 23:52:49 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: dogma....re: modules
Message-Id: <bj66kvkdh760aj6t5b6nqm7qaijg3cs7jc@4ax.com>
On Tue, 19 Aug 2003 22:33:32 -0500, Tony Curtis
<tony_curtis32@yahoo.com> wrote:
>> anything, but I think what I saw in CGI.pm wasn't too
>> much.
>
>You're either a troll or you really have no idea what
>you're going on about.
well...I meant the param and param_parse subroutines.
believe me...I am not a troll...why would I put up with all this
abuse... ;-)
------------------------------
Date: Tue, 19 Aug 2003 22:02:07 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: file upload in cgi
Message-Id: <e406kvsb6k5r1e9uhke1r6oqqt87eiht4m@4ax.com>
On Sun, 17 Aug 2003 23:11:26 +1200, "Tintin" <me@privacy.net> wrote:
>
>"Hudson" <scripts_you-know-the-drill_@hudsonscripting.com> wrote in message
>news:bhprjvok773hasvlrngbdug10vp9r7mumm@4ax.com...
>> very easy...I did it yesterday...if a file is over x bytes, stop the
>transfer
>> and unlink the file...what's so hard?
>
>Did you use you CGI parsing code that you previously posted to do the job?
>
oh...you will hate me for this, but it was a rewrite of some Matt's
script....but I did get it working. I didn't pay attention to the CGI
parsing part and just focused on the download part.
------------------------------
Date: Tue, 19 Aug 2003 22:03:34 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: file upload in cgi
Message-Id: <o606kvo6c4tc8hd1nrq9nleiqts269uuvn@4ax.com>
On Sun, 17 Aug 2003 10:27:24 +0200, Matija Papec <mpapec@yahoo.com>
>Now you know why some options are deprecated; it's always a good thing to
>know what are the limitations of some particular solution. It's nothing
>personal but people get sometimes nervous about "all-knowing" posters which
>periodically come with *very* similar and poor ideas. You just picked a few
>such ones.
Thanks Matija for the reply. Well...I am not an all-knowing poster,
but I think the dogma in this group is very thick indeed.
------------------------------
Date: 19 Aug 2003 19:37:56 -0700
From: jwillmore@cyberia.com (James Willmore)
Subject: Re: Low-level way of fetching UDP datagram as a unit
Message-Id: <e0160815.0308191837.4c804511@posting.google.com>
john_ramsden@sagitta-ps.com (John Ramsden) wrote in message news:<d27434e.0308190817.2952a05b@posting.google.com>...
> Anyway, apart from using a timeout, I was wondering if there is some
> lower-level Perl (or any) method of reading an UDP datagrams as a
> unit, so that this problem cannot arise.
>
> Also, I need solutions for Unix and Windows if possible, even if a
> different approach must be used for each.
There are several module on CPAN that could help - including one for SNMP.
http://search.cpan.org/
HTH
Jim
------------------------------
Date: Tue, 19 Aug 2003 21:32:04 -0400
From: Benjamin Goldberg <ben.goldberg@hotpop.com>
Subject: Re: Order of evaluation of expressions
Message-Id: <3F42CF94.8081FC0C@hotpop.com>
"John W. Krahn" wrote:
>
> Abigail wrote:
[snip]
> > Precedence isn't the same as order of evaluation.
>
> Yes I know. What I was trying to say is that the concatenation operator
> is left associative so that:
>
> shift(@a) . shift(@b) . shift(@c) . shift(@d)
>
> will be always be evaluated as:
>
> ( ( shift(@a) . shift(@b) ) . shift(@c) ) . shift(@d)
>
> unless you explicitly parenthesise the expression.
That's right.
> So it should follow that if shift(@a) . shift(@b) . shift(@c) is always
> evaluated before shift(@d) and shift(@a) . shift(@b) is always evaluated
> before shift(@c), shouldn't it follow that shift(@a) is evaluated before
> shift(@b)?
Who is saying that "shift(@a) . shift(@b) . shift(@c)" actually *IS*
always evaluated before "shift(@d)"? Maybe it is in current perls, but
AFAIK, it's NOT gauranteed to be so in the future.
Consider the following two bits of code:
$x{foo} ||= keys %x;
$y{foo} = keys %y;
Which side gets evaluated first? Remember, ||= and = are both right
associative. So what should $x{foo} and $y{foo} be?
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
------------------------------
Date: Tue, 19 Aug 2003 21:07:35 -0500
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: Order of evaluation of expressions
Message-Id: <Xns93DCE1251F9F8sdn.comcast@206.127.4.25>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
"John W. Krahn" <krahnj@acm.org> wrote in
news:3F42BCBC.276477FC@acm.org:
> Abigail wrote:
>>
>> John W. Krahn (krahnj@acm.org) wrote on MMMDCXL September MCMXCIII in
>> <URL:news:3F417BDC.7F24A9F3@acm.org>:
>> ==
>> == Just going by perlop.pod, shift() is a named unary operator which
>> has == lower precedence than . and . is left associative which would
>> mean it == would evaluate the left side first. Correct me if I'm
>> wrong. :-)
>>
>> Precedence isn't the same as order of evaluation.
>
> Yes I know. What I was trying to say is that the concatenation
> operator is left associative so that:
>
> shift(@a) . shift(@b) . shift(@c) . shift(@d)
>
> will be always be evaluated as:
>
> ( ( shift(@a) . shift(@b) ) . shift(@c) ) . shift(@d)
Parentheses don't control order of evaluation. Associativity is more
related to precedence than to order of evaluation.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN xxx SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP0LX+2PeouIeTNHoEQLCngCg8JhjLtdgN8+m/TZx4YmG3nyVW/4AniIa
Ei0TcxPoCAipEY6BQF5wmt1O
=DvP3
-----END PGP SIGNATURE-----
------------------------------
Date: Wed, 20 Aug 2003 02:10:16 GMT
From: "Vince" <duster@duster.com>
Subject: Perl help
Message-Id: <cMA0b.3583$3U.1954@newssvr27.news.prodigy.com>
I have a script at www.lahomebid.com
and would like to change the header and replace with a logo.gif and create
a left hand frame to the page with space for links.
If anyone can help, please email me and let me know how much it would be $$$
at info @ true-west.com
Thanks
------------------------------
Date: Wed, 20 Aug 2003 03:48:58 +0000 (UTC)
From: "David H. Adler" <dha@panix.com>
Subject: Re: Perl help
Message-Id: <slrnbk5rt9.bpn.dha@panix2.panix.com>
In article <cMA0b.3583$3U.1954@newssvr27.news.prodigy.com>, Vince wrote:
> If anyone can help, please email me and let me know how much it would
> be $$$ at info @ true-west.com
You have posted a job posting or a resume in a technical group.
Longstanding Usenet tradition dictates that such postings go into
groups with names that contain "jobs", like "misc.jobs.offered", not
technical discussion groups like the ones to which you posted.
Had you read and understood the Usenet user manual posted frequently to
"news.announce.newusers", you might have already known this. :) (If
n.a.n is quieter than it should be, the relevent FAQs are available at
http://www.faqs.org/faqs/by-newsgroup/news/news.announce.newusers.html)
Another good source of information on how Usenet functions is
news.newusers.questions (information from which is also available at
http://www.geocities.com/nnqweb/).
Please do not explain your posting by saying "but I saw other job
postings here". Just because one person jumps off a bridge, doesn't
mean everyone does. Those postings are also in error, and I've
probably already notified them as well.
If you have questions about this policy, take it up with the news
administrators in the newsgroup news.admin.misc.
http://jobs.perl.org may be of more use to you
Yours for a better usenet,
dha
--
David H. Adler - <dha@panix.com> - http://www.panix.com/~dha/
"We are the Borg. You will be assimilated! Nah, only kidding. We're
just the Sontarans. Care to take part in some 'medical research'?"
------------------------------
Date: Tue, 19 Aug 2003 22:42:33 -0400
From: Shawn Milochik <Shawn@Linurati.net>
Subject: Perl script vs. fetchmail & procmail
Message-Id: <pan.2003.08.19.22.42.33.43107.16205@Linurati.net>
I think I've learned enough to get started on this task I've set
for myself. The only thing I haven't decided is: How?
For all the reasons open source produces high-quality results, I'd
like to get input from some of you first.
Here's the project:
I want to download my mail, and optionally do zero or more
of the following:
1. Forward certain messages to another e-mail address.
2. Send a particular auto-response, depending upon sender.
3. E-mail a list of all e-mail senders/subjects to another e-mail address.
Then, I want to filter all messages through a Bayesian filter, probably
Spamassassin, then place the good messages back into my original
e-mail account, except in another box, such as "unread" instead of
back into the inbox, and spam into another box, such as "spam".
I do not want to use any of the user mail functionality of my
Linux server -- I just want to use my pop3/smtp e-mail account, and
I want everything to be put back into my pop3/smtp e-mail account
after it's been filtered, so that I can check it with webmail.
So the question is, should I use a hobbled together combination of
fetchmail, procmail, and sendmail (hereafter referred to as "FPS"),
or a Perl script?
Reasons for the Perl script/anti-FPS:
1. Since I don't want to use the mail capabilites of my Linux user account,
which is what FPS were designed for, I
think (not sure), that there is no specific benefit to using them.
2. If this project is to be useful to others later, then I think a
more "all-in-one" solution like this would be easier for others to
modify & implement than a series of config files for FPS.
3. A Perl solution would be more portable for people using an OS
other than the one it was developed on. I make this assertion because,
even if there are ports of FPS for other OSs, the user would still have
to download, install, and edit config files for three separate packages.
Reasons for FPS/anti-Perl:
1. FPS have all been around for a long time. They are basically
the standards, and have been tested by thousands of users at minimum.
2. Avoid inventing a different style wheel that rolls the same
as the original wheel.
3. FPS have so many features among them that a home-grown solution
for this particular problem may be restrictive to more advanced users
who wish to get extra functionality which could easily be gotten by
fiddling with FPS. Of course, one may argue that people who are that
able would already be using FPS or something else, and wouldn't bother
with my solution anyway.
These pro/con lists are not comprehensive; they are just some things
I thought of off of the top of my head. I'm really looking for
suggestions here.
When this is all done, the FPS config files will be posted with
documentation on Linurati.net or the Perl script will be made available
with documentation, under the GPL, of course. ;o)
Thanks in advance,
Shawn
Shawn@Linurati.net
------------------------------
Date: Tue, 19 Aug 2003 23:43:23 -0700
From: hudson <scripts_you_know_the_drill_@hudsonscripting.com>
Subject: Re: plouk zombie plouk zombie
Message-Id: <a366kvs0u1l86lr1aao7ug3f7horrplsj5@4ax.com>
On Tue, 19 Aug 2003 03:36:13 +0000, "serge.john.swilting"
<serge.john.swilting@wanadoo.fr> wrote:
>plouk
>plouk
>
>
>
>zombie
>zombie
>
>je crois que une personne à decouvert une chose assez super il y a peu de
>temps
>
>serge
hey serge...you're my hero! ;-)
------------------------------
Date: Tue, 19 Aug 2003 21:22:21 -0400
From: Benjamin Goldberg <ben.goldberg@hotpop.com>
Subject: Re: Quick removal of the begging of a file?
Message-Id: <3F42CD4D.9E1644A4@hotpop.com>
Ed Kulis wrote:
> Benjamin Goldberg wrote:
[snip]
> > Something like this:
> >
> > open( FH, "<+", $filename ) or die horribly;
> > seek( FH, ((-s FH)/2), 0 ) or die horribly; # 50%
> > scalar(<FH>); # skip to the end of the line.
> This is cool.
I got the idea of skipping to the end of the line this way from look.pl.
[snip]
> > If you leave out the stop_other_app_from_writing and
> > allow_other_app_to_write, then there's a chance you'll
> > some lines, due to a race condition.
>
> That's what puts the "curse" in "recursive"
Recursion is not involved.
The specific race condition I'm referring to is:
It's possible, that after you read the last stuff from the end
of the file, and before you truncate the file, the other app
could decide to add more lines.
If you've *blocked* app from writing, when you're reading the last stuff
from the file, then this cannot happen.
> > You might be better off rotating your log files every so often, then
> > removing the oldest ones. This is the standard technique for what you
> > want.
> >
> Yep. I was trying to be fancy so that a developer could always see the
> last x% of a file. BUT! why don't I just write it to another file before
> I do the cat /dev/null.
And what happens if, after you copy the last x% to another file, and
before you do the cat /dev/null, the other app decides to add more
lines?
This is the exact same race condtion I mentioned above.
> >> cat /dev/null > file
> >> sometimes works to zero the entire file while it's being written to
> >
> > This should *always* truncate the file to 0 length. Not "sometimes".
>
> Always truncates but I've had some gremline reports from developers that
> the app didn't like it and hung or crashed.
This isn't entirely surprising.
If the app does not use a filehandle in opened in write-only append
mode, then it might be seeking around in and reading from the file,
while at the same time you're truncating the file. It's not
unsurprising for the app to be confused, and hang or die.
> I don't quite believe it and I think is
> was the "Fallacy of the Last Change"
Not believing your users is also a fallacy :)
[snip]
> > True -- the inode stays the same, so it doesn't make a difference to
> > the app which is writing.
>
> Thanks for the confirm on this.
Actually, to be more pendantic, because the inode stays the same, the
app will continue writing to the same old file (even though it's now
truncated). Whereas, if you renamed the file and created a new, empty
one with the old name, the app would continue writing to the same *file*
(which now has a new name), instead of the new file with the old file's
name.
Note that "doesn't make a difference" only *truly* applies if the app
has the file opened in write-only append mode.
If the app has the file opened for reading (or reading and writing),
then definitely it makes a difference. If the app isn't using append
mode, and merely used seek to get to the end, new data printed will
*not* start appearing where you truncated the file to, and will instead
appear at the same offset that earlier writes are, thus creating a
"sparse file", with the new data someplace you really didn't expect it.
> > But if you want to keep recent data, then it *does* make a difference.
>
> Sounds like I can loop and post reads on the source log file and send
> the lines to other files of a certain fixed size then truncate the
> source log file from another process.
>
> Might lose a line or two but that doesn't make much difference in a
> verbose log.
>
> I can then manage the chunks of the log files and eliminate older ones.
If you don't mind losing a line or two, then it sounds like you've got
your solution.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
------------------------------
Date: Wed, 20 Aug 2003 01:49:01 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re: Regex - assign to new variable and replace in one line?
Message-Id: <3F42D367.5020709@rochester.rr.com>
Brad Walton wrote:
...
> $missionname = $check[1];
> $missionname =~ s/.mis//;
>
> I am trying to find a way to assign $missionname the same value as
> $check[1], and remove '.mis' from the variable, in one expression.
> This is really an efficiency issue, and also a learning experience for
> me.
...
> Brad
>
You indicate you are trying to remove the string '.mis' from the
variable. To do that, you should escape the . as it is a metacharacter.
If that is what you intend, something like:
($missionname = $check[1]) =~ s/\.mis//;
should work.
--
Bob Walton
------------------------------
Date: Wed, 20 Aug 2003 02:01:11 -0000
From: "David K. Wall" <usenet@dwall.fastmail.fm>
Subject: Re: Regex - assign to new variable and replace in one line?
Message-Id: <Xns93DCDFFEE7893dkwwashere@216.168.3.30>
Matija Papec <mpapec@yahoo.com> wrote:
> jw1454@sbc.com (Brad Walton) wrote:
>>I am trying to consolidate the following 2 lines, into 1 line.
>>
>>$missionname = $check[1];
>>$missionname =~ s/.mis//;
>
> s/.mis// for $missionname = $check[1];
I hadn't seen that before -- and now that I have, I think I'll try to forget
it. :-)
> this one is most common and recommended:
> ($missionname = $check[1]) =~ s/.mis//;
------------------------------
Date: Wed, 20 Aug 2003 11:56:54 +1000
From: Simon Taylor <simon@unisolve.com.au>
Subject: Re: Regular Expression Question
Message-Id: <bhukk4$1kkn$1@otis.netspace.net.au>
Awrigh01 wrote:
> Sorry about not being clear. I appreciate the help so far. I am
> searching through a text file read through line by line.
>
> I want to be able to identify word patterns that occur consecutively
> in the same line, such as: A Man Walks Down The Street. (including the
> spaces)
>
> This regular expression identifies this pattern:
> [A-Z]\w*(\s+[A-Z]\w*)*.
>
> However, there is another twist, sometimes the pattern will include a
> comma, dash, hyphen, an "&", or a period, such as Johnson & Johnson
> CauLife Ins. Co.
>
> I can't figure out how to generally identify both "A Man Walks Down
> The Street" and "Johnson & Johnson CauLife Ins. Co." in one regular
> expression.
Here is a snippet of code that matches lines in a file that contain only
words that start with an upper-case character, as well the other cases
you've mentioned.
#!/usr/bin/perl -w
use strict;
while (<>) {
print " line: $_";
print "matched: $_" if ($_ =~ m/^([A-Z&]\S*\s*)+$/);
}
and here is the sample data file I used:
Cats
Cats And Dogs
Ignore this line?
A Man Walks Down The Street
Johnson & Johnson CauLife Ins. Co.
johnson & johnson CauLife Ins. Co. - Gets Ignored
Ignore this line, also?
Should, See This Line
Should-see This Line
It works as I think you intend.
However, I can't help but wondering whether we are building a regular
expression that is in danger of being too-specific and therefore a bit
fragile.
Sometimes it pays to think negatively with RE's. Identify the stuff that
you don't want to match and do away with it first. This often results in
code that runs faster and the analysis that it forces you to do helps
clear up what it is you're really after.
Hope this helps.
Also check out
perldoc perlre
Regards,
Simon Taylor
------------------------------
Date: 19 Aug 2003 20:22:15 -0700
From: wherrera@lynxview.com (Bill)
Subject: Re: Why a sudden taint error with change in ISP server's perl 5 version?
Message-Id: <239ce42f.0308191922.67d7cd1@posting.google.com>
Pardon the typos; I was trying to simplify things as I typed.
The server changed, apparently, from
Linux Apache/1.3.20 (Unix) ApacheJServ/1.1.2 PHP/4.0.4pl1
FrontPage/5.0.2.2510 Rewrit/1.1a
to
Linux Apache/1.3.27 (Unix) PHP/4.2.3 FrontPage/5.0.2.2510 Rewrit/1.1a
and taint checking with it.
> > if($tainted && open(OUTFILE, ">filename")) { print OUTFILE "data\n" }
> anyway, i believe this is because (from perlsec):
> | The value of an expression containing tainted data will
> | itself be tainted, even if it is logically impossible for
> | the tainted data to affect the value.
>
> so the $tainted is in the same expression as the open().
I guess this is it. However, how does
open(OUTFILE, ">filename") CONTAIN $tainted? It doesn't. I can see
open(OUTFILE, ">filename" || $tainted)
as containing a $tainted that cannot logically be used, but not what I
did.
Does the taint checking not look at logic or parse structure, but just
look at lines, or blocks of code or such, on some platforms?
BTW, Thanks for the help!
--Bill
------------------------------
Date: Sat, 19 Jul 2003 01:59:56 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re:
Message-Id: <3F18A600.3040306@rochester.rr.com>
Ron wrote:
> Tried this code get a server 500 error.
>
> Anyone know what's wrong with it?
>
> if $DayName eq "Select a Day" or $RouteName eq "Select A Route") {
(---^
> dienice("Please use the back button on your browser to fill out the Day
> & Route fields.");
> }
...
> Ron
...
--
Bob Walton
------------------------------
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 5393
***************************************
