[22568] in Perl-Users-Digest
Perl-Users Digest, Issue: 4789 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Mar 30 21:11:11 2003
Date: Sun, 30 Mar 2003 18:10:10 -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, 30 Mar 2003 Volume: 10 Number: 4789
Today's topics:
Re: CGI.pm or roll-your-own? <raven@corax.org>
Re: CGI.pm or roll-your-own? <raven@corax.org>
Re: CGI.pm or roll-your-own? <raven@corax.org>
Re: CGI.pm or roll-your-own? <raven@corax.org>
Re: CGI.pm or roll-your-own? <uri@stemsystems.com>
Re: CGI.pm or roll-your-own? <uri@stemsystems.com>
Re: CGI.pm or roll-your-own? <noreply@gunnar.cc>
Re: CGI.pm or roll-your-own? <noreply@gunnar.cc>
Re: CGI.pm or roll-your-own? <raven@corax.org>
Re: CGI.pm or roll-your-own? <raven@corax.org>
Re: CGI.pm or roll-your-own? <raven@corax.org>
Re: CGI.pm or roll-your-own? (Randal L. Schwartz)
Re: CGI.pm or roll-your-own? (Randal L. Schwartz)
Re: CGI.pm or roll-your-own? <raven@corax.org>
Re: CGI.pm or roll-your-own? <noreply@gunnar.cc>
Re: CGI.pm or roll-your-own? (Sam Holden)
Re: CGI.pm or roll-your-own? <wsegrave@mindspring.com>
Re: CGI.pm or roll-your-own? <wsegrave@mindspring.com>
Re: CGI.pm or roll-your-own? (Randal L. Schwartz)
CGI::ContactForm 1.03 - Feedback request <noreply@gunnar.cc>
Perl and AIM question. (PJ)
Re: Perl and objects <mail@annuna.com>
seemingly simple problem (Jan Snajder)
Re: seemingly simple problem <casey@geeknest.com>
Re: suid not working <root@localhost.spam.me.not>
webhosts that support perl well? (dan baker)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 30 Mar 2003 21:47:23 GMT
From: Greg Raven <raven@corax.org>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <raven-F39F3C.13472030032003@netnews.attbi.com>
In article <b5qiap$2c7au1$1@ID-172104.news.dfncis.de>,
"Tintin" <me@privacy.net> wrote:
> Well, post your parsing code and we'll tell you where it is broken and
> insecure.
Thanks for the offer, but what i was looking for was something along the
lines of cgi-lib.pl, the latest version of which works perfectly for me.
------------------------------
Date: Sun, 30 Mar 2003 21:53:46 GMT
From: Greg Raven <raven@corax.org>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <raven-E954ED.13534530032003@netnews.attbi.com>
In article <3e817fe5.4055961764@news.cis.dfn.de>,
helgi@decode.is (Helgi Briem) wrote:
> But "why?" Why do people, beginners no less, constantly
> want to write this themselves when using the CGI module
> is almost infinitely easier (not to mention better).
I can't tell you why other beginners do it, but I can tell you why I am
doing it: CGI.pm seems like another language. Oh, it looks great at
grabbing the GET or PUT information, but getting the information back
out of CGI.pm seems more akin to pulling teeth than writing code.
Of course, I am a beginner, and I'm much more fluent in HTML than perl,
so anything that allows me to work more confortably with HTML is going
to seem "better."
--
Greg Raven
------------------------------
Date: Sun, 30 Mar 2003 22:06:06 GMT
From: Greg Raven <raven@corax.org>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <raven-06E71F.14060530032003@netnews.attbi.com>
In article <slrnb86k1u.4ck.tadmc@magna.augustmail.com>,
tadmc@augustmail.com (Tad McClellan) wrote:
> Rather than have them learn the 2 lines of code they'd need
> with CGI.pm, you would have them learn a Whole Lot More lines
> of punctuation-intensive gobbledy gook?
>
> How can that be better for an already overloaded beginner?
Let me give you an example. Let's say that the AOB wants to try CGI.pm,
and comes across this:
#!/usr/local/bin/perl -w
use CGI; # load CGI routines
$q = new CGI; # create new CGI object
print $q->header, # create the HTTP header
$q->start_html('hello world'), # start the HTML
$q->h1('hello world'), # level 1 header
$q->end_html; # end the HTML
As as self-proclaimed AOB, I get lines one and two; from line three on,
the mystery begins.
I realize that the documentation probably gives a more straightforward
method of using CGI.pm, but there is so bloody much of it, in such
non-beginner language (even finding it isn't straightforward -- perldoc
CGI? Why not perldoc CGI.pm?), that after the dazzle of what can be done
wears off, all that's left is the puzzlement as to how to do any of it.
With a cgi-lib.pl-type of construction, everything seems more or less to
be right in front of you.
--
Greg Raven
------------------------------
Date: Sun, 30 Mar 2003 22:08:56 GMT
From: Greg Raven <raven@corax.org>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <raven-2A7D46.14085530032003@netnews.attbi.com>
In article <509b3630abaf9f679c15b75f1866e1d0@news.teranews.com>,
merlyn@stonehenge.com (Randal L. Schwartz) wrote:
> In the same way that you have:
>
> #!/usr/bin/perl
>
> ... 40 lines of cgi-lib cargo-cult crap ...
>
> my $name = $FORM{name};
> my $age = $FORM{age};
>
> ... rest of program ...
>
> You can instead have:
>
> #!/usr/bin/perl
>
> use CGI "param";
>
> my $name = param('name');
> my $age = param('age');
>
> ... rest of program ...
>
> You don't have to change a single other thing.
I sure wish it was presented this way in the documentation!
--
Greg Raven
------------------------------
Date: Sun, 30 Mar 2003 22:25:55 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <x7of3swky4.fsf@mail.sysarch.com>
>>>>> "GR" == Greg Raven <raven@corax.org> writes:
GR> In article <b5qiap$2c7au1$1@ID-172104.news.dfncis.de>,
GR> "Tintin" <me@privacy.net> wrote:
>> Well, post your parsing code and we'll tell you where it is broken and
>> insecure.
GR> Thanks for the offer, but what i was looking for was something
GR> along the lines of cgi-lib.pl, the latest version of which works
GR> perfectly for me.
have you even followed this thread at all? that library is not supported
anymore, it doesn't have all the security stuff that cgi.pm has and it
has a very poor interface for multivalued widgets. so why are you using
it?
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Sun, 30 Mar 2003 22:26:47 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <x7llywwkwo.fsf@mail.sysarch.com>
>>>>> "GR" == Greg Raven <raven@corax.org> writes:
GR> In article <509b3630abaf9f679c15b75f1866e1d0@news.teranews.com>,
GR> merlyn@stonehenge.com (Randal L. Schwartz) wrote:
>>
>> use CGI "param";
>>
>> my $name = param('name');
>> my $age = param('age');
>>
>> ... rest of program ...
>>
>> You don't have to change a single other thing.
GR> I sure wish it was presented this way in the documentation!
it is.
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Mon, 31 Mar 2003 01:19:12 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <b67u2h$2ja9i$1@ID-184292.news.dfncis.de>
Tore Aursand wrote:
> A couple of years ago there were _thousands_ of scripts using CGI.pm on
> the web. Nobody had ever heard about DoS (for instance). Then DoS rose
> from hell, and scripters shivered.
>
> Thanks to CGI.pm, there where only _one_ file on the planet that needed
> correction. That same file was uploaded to _one_ site (CPAN). All those
> who had been using CGI.pm could use _one_ utility to update their server.
As you may have seen in another post, I have taken my first steps as
regards CGI.pm. One of the things I noticed was that you need to set a
variable in order to have CGI.pm check the size of STDIN, so your
example does not illustrate the 'magic' of CGI IMO. After all,
checking $ENV{'CONTENT_LENGTH'} directly isn't appreciably harder, is it?
/ Gunnar
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 31 Mar 2003 01:34:56 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <b67v02$2h4h7$1@ID-184292.news.dfncis.de>
Peter Scott wrote:
> In article <b64khs$1j9ee$1@ID-184292.news.dfncis.de>,
> Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
>
>>>There's REALLY NO WIN for a hand-rolled CGI parsing code.
>>
>>To me it is, since
>>1) I know what I need to know to do what I do, and
>
> No, several people have pointed out that there are a number of things
> you needed to do that you didn't know had to be done, like guarding
> against DoS attacks.
Well, I have just found that that isn't *automatically* done even if
you use CGI.pm.
>>2) I haven't (yet) studied CGI.pm enough to feel comfortable with it.
>
> Let me help:
>
> use CGI qw(param);
> my $form_input = param('form_input');
Okay, thanks. :) Basically that is what I did.
> The CGI.pm documentation is a bit long because it covers so many
> things,
True.
Have it ever been considered to split CGI.pm into more than one
module, or maybe a main CGI.pm module that loads a number of sub
modules? I'm thinking of a CGI::Param module, for instance, that you
could use without loading the rest of it.
And the documentation should of course be splitted accordingly...
/ Gunnar
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 31 Mar 2003 00:16:32 GMT
From: Greg Raven <raven@corax.org>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <raven-5591E8.16163130032003@netnews.attbi.com>
In article <x7of3swky4.fsf@mail.sysarch.com>,
Uri Guttman <uri@stemsystems.com> wrote:
> GR> Thanks for the offer, but what i was looking for was something
> GR> along the lines of cgi-lib.pl, the latest version of which works
> GR> perfectly for me.
>
> have you even followed this thread at all? that library is not supported
> anymore, it doesn't have all the security stuff that cgi.pm has and it
> has a very poor interface for multivalued widgets. so why are you using
> it?
I've tried to follow the thread. I understand that there may be security
issues, but that's pretty abstract for a beginner. As for the library
not being supported, as long as it runs as expected, I don't see the
problem. More beginner myopia, no doubt.
--
Greg Raven
------------------------------
Date: Mon, 31 Mar 2003 00:33:35 GMT
From: Greg Raven <raven@corax.org>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <raven-5783A7.16333530032003@netnews.attbi.com>
In article <b673tn$6p1$1@slb9.atl.mindspring.net>,
"William Alexander Segraves" <wsegrave@mindspring.com> wrote:
> If Greg Bacon would kindly follow Tad's advice, he might get a response that
> is helpful to him. OTOH, I see he checked out about 65 messages ago, perhaps
> having given up on getting help here.
>
> There have been some very interesting and informative side-threads that have
> resulted from Greg's choice of subject.
That darned Greg Bacon! :-)
Actually, I kept NewsWatcher running in the background for a couple of
days, checking to see the responses. However, the responses were fairly
slaw at first, and in the meantime, I discovered cgi-lib.pl version
2.18, which worked exactly the way I wanted and expected it to. I
checked into the newsgroup today, I was astonished to find 70+ messages
in this thread.
On the basis of what Randal Schwartz and others have posted, I'm going
to have another look at CGI.pm. I'm slated soon to take over a web site
that makes fairly heavy use of perl, and the input coding on the CGI
side isn't even up to the cgi-lib.pl standard -- that is, each field
value is "hand-harvested" from the form, for assignment to a variable.
(That is, there is no looping through the fields/field values.) I figure
that just about anything is an improvement.
--
Greg Raven
------------------------------
Date: Mon, 31 Mar 2003 00:43:17 GMT
From: Greg Raven <raven@corax.org>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <raven-0DC5C0.16431730032003@netnews.attbi.com>
In article <b6782b$iq9$2@slb6.atl.mindspring.net>,
"William Alexander Segraves" <wsegrave@mindspring.com> wrote:
> Also, Greg, a GG search for "Perl vs. Perl & CGI.pm " will show you a
> year-old thread, in which the contributions from some of the luminaries of
> this ng illuminate the issues in which you are interested.
Got it. Thanks.
--
Greg Raven
------------------------------
Date: Mon, 31 Mar 2003 00:51:45 GMT
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <93c07fb2255fd9ed86b069c268f652e7@news.teranews.com>
>>>>> "Gunnar" == Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
Gunnar> Have it ever been considered to split CGI.pm into more than one
Gunnar> module, or maybe a main CGI.pm module that loads a number of sub
Gunnar> modules? I'm thinking of a CGI::Param module, for instance, that you
Gunnar> could use without loading the rest of it.
The code already "doesn't load" what it doesn't need. As probably the
third or fourth most frequently "used" module on the planet, there's
been a lot of focus on it over the years.
Gunnar> And the documentation should of course be splitted accordingly...
OK, I'm trying very hard not to make a comment about "search" and
"learn to use a scroll bar".
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: Mon, 31 Mar 2003 00:51:46 GMT
From: merlyn@stonehenge.com (Randal L. Schwartz)
To: Greg Raven <raven@corax.org>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <ba0e8069bbbe7a341de5494e707cc50f@news.teranews.com>
>>>>> "Greg" == Greg Raven <raven@corax.org> writes:
Greg> Let me give you an example. Let's say that the AOB wants to try CGI.pm,
Greg> and comes across this:
Greg> #!/usr/local/bin/perl -w
Greg> use CGI; # load CGI routines
Greg> $q = new CGI; # create new CGI object
Greg> print $q->header, # create the HTTP header
Greg> $q->start_html('hello world'), # start the HTML
Greg> $q->h1('hello world'), # level 1 header
Greg> $q->end_html; # end the HTML
And Lincoln Stein himself wouldn't write it that way. He'd say:
#!/usr/bin/perl
use CGI ":all";
print
header,
start_html('hello_world'),
h1('hello_world'),
end_html;
That "object" junk is getting in your way. And it's not necessary.
Look at any tutorial Lincoln has presented at conferences. Never the
object form. Always the shortcut form.
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: Mon, 31 Mar 2003 00:56:38 GMT
From: Greg Raven <raven@corax.org>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <raven-A3F0B1.16563530032003@netnews.attbi.com>
In article <ba0e8069bbbe7a341de5494e707cc50f@news.teranews.com>,
merlyn@stonehenge.com (Randal L. Schwartz) wrote:
> Greg> Let me give you an example. Let's say that the AOB wants to try CGI.pm,
> Greg> and comes across this:
>
> Greg> #!/usr/local/bin/perl -w
> Greg> use CGI; # load CGI routines
> Greg> $q = new CGI; # create new CGI object
> Greg> print $q->header, # create the HTTP header
> Greg> $q->start_html('hello world'), # start the HTML
> Greg> $q->h1('hello world'), # level 1 header
> Greg> $q->end_html; # end the HTML
>
> And Lincoln Stein himself wouldn't write it that way. He'd say:
>
> #!/usr/bin/perl
>
> use CGI ":all";
> print
> header,
> start_html('hello_world'),
> h1('hello_world'),
> end_html;
>
> That "object" junk is getting in your way. And it's not necessary.
> Look at any tutorial Lincoln has presented at conferences. Never the
> object form. Always the shortcut form.
I copied this from perldoc CGI, and pasted in as an example. To bad
Lincoln Stein didn't help create the documentation. (He didn't, did he?)
--
Greg Raven
------------------------------
Date: Mon, 31 Mar 2003 03:07:17 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <b684da$2jo0s$1@ID-184292.news.dfncis.de>
Randal L. Schwartz wrote:
>>>>>>"Gunnar" == Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
> Gunnar> Have it ever been considered to split CGI.pm into more than one
> Gunnar> module, or maybe a main CGI.pm module that loads a number of sub
> Gunnar> modules? I'm thinking of a CGI::Param module, for instance, that you
> Gunnar> could use without loading the rest of it.
>
> The code already "doesn't load" what it doesn't need.
I know that you don't need to import all the symbols, but the whole
thing is still compiled, isn't it?
> Gunnar> And the documentation should of course be splitted accordingly...
>
> OK, I'm trying very hard not to make a comment about "search" and
> "learn to use a scroll bar".
I don't understand what you mean by that, but I guess it's another way
to say that CGI.pm is The Ultimate Solution in every conceivable respect.
/ Gunnar
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 31 Mar 2003 01:26:29 GMT
From: sholden@flexal.cs.usyd.edu.au (Sam Holden)
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <slrnb8f6a4.a0k.sholden@flexal.cs.usyd.edu.au>
On Mon, 31 Mar 2003 00:56:38 GMT, Greg Raven <raven@corax.org> wrote:
> In article <ba0e8069bbbe7a341de5494e707cc50f@news.teranews.com>,
> merlyn@stonehenge.com (Randal L. Schwartz) wrote:
>
>> Greg> Let me give you an example. Let's say that the AOB wants to try CGI.pm,
>> Greg> and comes across this:
>>
>> Greg> #!/usr/local/bin/perl -w
>> Greg> use CGI; # load CGI routines
>> Greg> $q = new CGI; # create new CGI object
>> Greg> print $q->header, # create the HTTP header
>> Greg> $q->start_html('hello world'), # start the HTML
>> Greg> $q->h1('hello world'), # level 1 header
>> Greg> $q->end_html; # end the HTML
>>
>> And Lincoln Stein himself wouldn't write it that way. He'd say:
>>
>> #!/usr/bin/perl
>>
>> use CGI ":all";
>> print
>> header,
>> start_html('hello_world'),
>> h1('hello_world'),
>> end_html;
>>
>> That "object" junk is getting in your way. And it's not necessary.
>> Look at any tutorial Lincoln has presented at conferences. Never the
>> object form. Always the shortcut form.
>
> I copied this from perldoc CGI, and pasted in as an example. To bad
> Lincoln Stein didn't help create the documentation. (He didn't, did he?)
And a couple of paragraphs below it is the non-OO version.
The documentation documents both interfaces of course. It uses OO examples
in preference to non-OO examples, I suspect because while more cumbersome
to use they are safer to cut-n-paste (no subroutine name clashes from the
import), and provide a slightly richer interface (handling multiple
CGI instances at once, such as restoring one from disk and also processing
the current one - though I can't see why you would do such a thing).
Why anyone would actually use the OO interface is beyond me, since it is
a domain in which in the *vast* majority of cases you only have one instance
(I have *never* needed multiple CGI objects in one script).
--
Sam Holden
------------------------------
Date: Sun, 30 Mar 2003 19:13:34 -0600
From: "William Alexander Segraves" <wsegrave@mindspring.com>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <b685te$cqv$1@slb2.atl.mindspring.net>
"Greg Raven" <raven@corax.org> wrote in message
news:raven-06E71F.14060530032003@netnews.attbi.com...
> In article <slrnb86k1u.4ck.tadmc@magna.augustmail.com>,
> tadmc@augustmail.com (Tad McClellan) wrote:
>
> > Rather than have them learn the 2 lines of code they'd need
> > with CGI.pm, you would have them learn a Whole Lot More lines
> > of punctuation-intensive gobbledy gook?
> >
> > How can that be better for an already overloaded beginner?
>
> Let me give you an example. Let's say that the AOB wants to try CGI.pm,
> and comes across this:
>
> #!/usr/local/bin/perl -w
> use CGI; # load CGI routines
> $q = new CGI; # create new CGI object
> print $q->header, # create the HTTP header
> $q->start_html('hello world'), # start the HTML
> $q->h1('hello world'), # level 1 header
> $q->end_html; # end the HTML
>
> As as self-proclaimed AOB, I get lines one and two; from line three on,
> the mystery begins.
Greg, you are not compelled to create a new CGI object. Perhaps the
following code would have been more comprehensible for you:
#!/usr/local/bin/perl -w
use strict;
use CGI qw(:standard);
print header, start_html('hello world'), h1('hello world'), end_html;
You might search for "Function-Oriented vs Object-Oriented Use" in CGI.htm
on Lincoln Stein's web site.
Cheers.
Bill Segraves
------------------------------
Date: Sun, 30 Mar 2003 19:32:51 -0600
From: "William Alexander Segraves" <wsegrave@mindspring.com>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <b685tf$cqv$2@slb2.atl.mindspring.net>
"Greg Raven" <raven@corax.org> wrote in message
news:raven-5783A7.16333530032003@netnews.attbi.com...
<snip>
> On the basis of what Randal Schwartz and others have posted, I'm going
> to have another look at CGI.pm. I'm slated soon to take over a web site
> that makes fairly heavy use of perl, and the input coding on the CGI
> side isn't even up to the cgi-lib.pl standard -- that is, each field
> value
You mean name, I think.
> is "hand-harvested" from the form, for assignment to a variable.
> (That is, there is no looping through the fields/field values.) I figure
> that just about anything is an improvement.
Hand harvested? Would you still do that if you knew you could loop through
and print out all of the name value pairs of a form without knowing the
names?
For example:
#!perl -w
use strict;
use CGI qw(-no_xhtml :standard);
print header, start_html;
foreach (param()) {print $_, ' = ', join(', ', param($_)), "\n"}
print end_html;
For me, this (or some variation of it) is a lot faster than "hand-harvesting
the name-value pairs from an HTML or PDF form. YMMV.
Cheers.
Bill Segraves
------------------------------
Date: Mon, 31 Mar 2003 02:01:42 GMT
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <5f8bd4d7817b54049411d83cef1ae6aa@news.teranews.com>
>>>>> "Gunnar" == Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
>> The code already "doesn't load" what it doesn't need.
Gunnar> I know that you don't need to import all the symbols, but the whole
Gunnar> thing is still compiled, isn't it?
No, it uses a variant of "SelfLoader" called "the lincoln loader". It
compiles code of itself only as necessary.
Really. This can be answered by looking at the code. Why do you keep
challenging me EVERY TIME I say something to you?
--
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: Mon, 31 Mar 2003 00:51:06 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: CGI::ContactForm 1.03 - Feedback request
Message-Id: <b67sds$2kiu6$1@ID-184292.news.dfncis.de>
Hi all,
First: To those of you who have followed the discussion in the thread
"CGI.pm or roll-your-own?": I have listened, and decided to start
using CGI.pm in my module for parsing form data. The new version is
available at http://search.cpan.org/author/GUNNAR/
To many (most?) of you, CGI::ContactForm is a very trivial piece of
software. Its purpose is to make it *very* easy to create an unlimited
number of web contact forms. It's not a general tool for creating
forms; there are already quite a few of those out there. It's just
doing one thing, but it's doing it with a minimum of user effort.
This is my first try to share code via CPAN, and I would very much
appreciate your feedback on the usefulness of the module, code
details, etc. If you want to see what it outputs, you can simply click
the email link in the signature below. (I don't mind if you send a
test message. :) )
Looking forward to your comments.
/ Gunnar
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 30 Mar 2003 11:12:48 -0800
From: perlmod@yahoo.com (PJ)
Subject: Perl and AIM question.
Message-Id: <6775b086.0303301112.fe6f7fb@posting.google.com>
I have developed a basic HTML grabber that checks my favorite news
site every 30 seconds. When if finds something cool, it emails me the
headline.
I would now like it to send IM me the headline.
I have installed Net:AIM but can't figure out how to send a basic
message.
This is what I have:
use Net::Aim;
my $username = 'somename';
my $password = 'somepassword';
my $conn = $aim->newconn(Screenname => $username, Password =>
$password)
or die "Can't connect to Aim Server.\n";
while(1) {
if grabber finds a new headline {
$aim->send_im('user', $headline);
}
sleep 30;
}
### End Code
So, what do I need to add or change so that it simply IMs me the
headline?
Thanx in advance--
Casey
------------------------------
Date: Sun, 30 Mar 2003 18:20:08 -0600
From: Joe Creaney <mail@annuna.com>
Subject: Re: Perl and objects
Message-Id: <3E8789B8.3060904@annuna.com>
Yes I am very confused. I have been trying to read up on it but don't
realy get what they are trying to say. My problem is that I have no
formal training in modern program methods. I learned some programming
back in highschool in apple IIEs and from copying programs from
magizines. I havn't seen any simple demo programs with objects. I only
realy became awaire of object programming when I picked up a C++ book.
From my short intro to C++ I don't like it very much. Perl is so much
easier to work with and is much more powerful. I just like how objects
and classes were introduced in the C++ book.
Tassilo v. Parseval wrote:
> Also sprach Joe Creaney:
>
>
>>I have been looking a simple object in the programming perl book. I
>>think I wrote a simple class. It is a simple player class that will
>>have his name and x and y location for walking on a simple map.
>
>
> Well, no, you wrote a subroutine named player(), but there is no class.
>
>
>>#!/user/bin.perl
>>use strict;
>>my $n;
>>
>>
>>sub player {
>> my $char = {};
>> my $self;
>> $char -> name()
>> $char -> xcord();
>> $char -> ycord();
>
>
> $char is only a reference to an anonymous hash. It is no object so you
> can't call any methods upon it.
>
>
>> bless $self, $char;
>
>
> You can't use it as the second argument for bless() either. Simplified:
> the first argument to bless is the object (more correctly: the thing
> that is eventually going to be the object) and the second argument is a
> string denoting the name of the class the thing should belong to:
>
> bless $thing, "Player";
> # $thing is now a Player
>
>
>> return $char;
>> }
>>
>>print "Your name sir:";
>>
>>$n = <STDIN>;
>>** -> player ($char{name(->$n}); <-**
>>
>>The marked spot is where I am having trouble. I created a simple class
>>and a few objects in C++ but here seems very different.
>
>
> You are having these problems because you seem to be confused about a
> few things. Before you can create objects, you need a class. In Perl, a
> class is simply a package, therefore a player-class would begin like
> that:
>
> package Player;
>
> After that you need a method that constructs your objects. This
> function is unsurprisingly called the constructor. It's a common
> convention to call this method new(). You can do some initializations
> there as well, but the only important part for the moment is that you
> bless() in this method:
>
> sub new {
> # the name of this class
> my $class = shift;
>
> # this will be the object later: we use a hash-reference
> my $self = { name => undef,
> x => 0,
> y => 0 };
>
> # this hash-reference is now told to be an instance
> # of $class
> bless $self, $class;
>
> # the constructor returns an object:
> return $self;
> }
>
> Now that you have an object with some attributes ('name', 'x' and 'y'),
> you should add some accessor methods to set and retrieve these values:
>
> sub set_name {
> # $self is again the object itself
> my ($self, $name) = @_;
> $self->{ name } = $name;
> }
>
> sub get_name {
> my $self = shift;
> return $self->{ name };
> }
>
> Add similar methods for the position on the map (the attributes 'x' and
> 'y').
>
> Now you can start creating new Players with 'Player->new'.
>
> Tassilo
------------------------------
Date: 30 Mar 2003 12:17:52 -0800
From: jsnajder@inet.hr (Jan Snajder)
Subject: seemingly simple problem
Message-Id: <5d736387.0303301217.529e5dba@posting.google.com>
Hi!,
I am new to Perl, to this will be a silly question for most of you
guys.
I need a script that will convert all pathnames contained within a
file into pathnames with uppercase.
For example, a line within a file containing
"blah blah ../../Installer/SystemFiles blah blah" shall be converted
to
"blah blah ../../INSTALLER/SYSTEMFILES blah blah".
I've just spent 3 hours trying to figure out how to do it...
It seems so simple :)
thanx,
jan
------------------------------
Date: 30 Mar 2003 16:28:51 -0500
From: Casey West <casey@geeknest.com>
Subject: Re: seemingly simple problem
Message-Id: <20030330163333465-0500@news.highvision.net>
In <5d736387.0303301217.529e5dba@posting.google.com> Jan Snajder wrote:
: Hi!,
: I am new to Perl, to this will be a silly question for most of you
: guys.
:
: I need a script that will convert all pathnames contained within a
: file into pathnames with uppercase.
:
: For example, a line within a file containing
: "blah blah ../../Installer/SystemFiles blah blah" shall be converted
: to
: "blah blah ../../INSTALLER/SYSTEMFILES blah blah".
:
: I've just spent 3 hours trying to figure out how to do it...
: It seems so simple :)
Perl has a really nice function called uc(). The documentation can be
found by going to the shell and typing:
perldoc -f uc
In any case, say your path is in a variable called $path.
$path = uc $path;
Enjoy!
--
Casey West
------------------------------
Date: Sun, 30 Mar 2003 21:18:13 GMT
From: "Phil Langerholc" <root@localhost.spam.me.not>
Subject: Re: suid not working
Message-Id: <paJha.12398$_14.525@nwrdny02.gnilink.net>
Here are my permissions settings
kenny:/usr/local/bin# ls -l suidtest.pl
-rwsr-xr-x 1 root system 350 Mar 29 16:35 suidtest.pl
As you can see they are 4755, and the script still gives the results I have
indicated below. I'm wondering if this has something to do with the way IBM
compiled Perl when they shipped it with AIX....
> > I am having a problem with Perl trying to suid on AIX 4.3.3, ML is 11.
I
> > am using the perl that comes with AIX , 5.005_03 because I have several
> > different customer sets I support and they want the "vendor supplied"
> > version on their systems.
> >
> > I've Googled and not found too much on this for AIX aside from some
overflow
> > vulnerabilities in pervious versions of AIX.
>
> You did not mention set user, group and permissions of script (typically
> 4755 for suid). If you expect a Perl script to run suid, then suidperl
> has to be suid root (is NOT by default due to security concerns). If
> suidperl is suid root and suid root script is run by normal user:
>
> #!/usr/bin/perl -wU
> $ENV{PATH} = '';
> delete @ENV{qw(IFS CDPATH ENV BASH_ENV)};
> system("/usr/bin/whoami");
> print "EUID $>\tUID $<\nEGID $)\tGID $(\n";
> $< = $>; $( = $) = 0;
> system("/usr/bin/whoami");
> print "EUID $>\tUID $<\nEGID $)\tGID $(\n";
>
> Results for me in Linux:
> root
> EUID 0 UID 501
> EGID 503 500 100 80 503 GID 503 500 100 80 503
> root
> EUID 0 UID 0
> EGID 0 500 100 80 503 GID 0 500 100 80 503
>
> --
> David Efflandt - All spam ignored http://www.de-srv.com/
> http://www.autox.chicago.il.us/ http://www.berniesfloral.net/
> http://cgi-help.virtualave.net/ http://hammer.prohosting.com/~cgi-wiz/
------------------------------
Date: 30 Mar 2003 17:19:56 -0800
From: botfood@yahoo.com (dan baker)
Subject: webhosts that support perl well?
Message-Id: <13685ef8.0303301719.33912bb9@posting.google.com>
I realize this is not a *pure* perl question..... but I'm looking for
some feedback from perl programmers who may have found some reasonable
web hosts that do a good job supporting sites with custom scripts.
The host I've been using a lot for the last couple years has been
having increasing trouble with *growing pains* and service has fallen
by the wayside. They recently suffered some attacks from hackers and
one server has been down for 48 hours now with domains dead in the
water; no mirror, no backups, etc.
anyway, if anyone has a couple hosts they like to use, that support
custom perl scripts in user cgi-bin, and hopefully other common
features like .htaccess for specific password protection, please post
their URL so I can go check them out....
mucho gracias,
D
------------------------------
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 4789
***************************************
