[23795] in Perl-Users-Digest
Perl-Users Digest, Issue: 5998 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 29 18:32:53 2004
Date: Thu, 29 Jan 2004 15:32:25 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 29 Jan 2004 Volume: 10 Number: 5998
Today's topics:
Re: bbs problem + using cgi <Joe.Smith@inwap.com>
Re: bbs problem + using cgi <robin@csf.edu>
Re: bbs problem + using cgi <Joe.Smith@inwap.com>
Re: bbs problem + using cgi <noreply@gunnar.cc>
Re: bbs problem + using cgi <noreply@gunnar.cc>
Re: bbs problem + using cgi <flavell@ph.gla.ac.uk>
Re: bbs problem + using cgi <noreply@gunnar.cc>
Re: bbs problem + using cgi <gnari@simnet.is>
Re: bbs problem <dwall@fastmail.fm>
Re: bbs problem <karlheinz.weindl@oooonlinehome.de>
Re: bbs problem <1usa@llenroc.ude>
Re: bbs problem <karlheinz.weindl@oooonlinehome.de>
Re: bbs problem <1usa@llenroc.ude>
Re: bbs problem <robin@csf.edu>
Re: bbs problem <Joe.Smith@inwap.com>
Re: bbs problem <robin@csf.edu>
Re: bbs problem <uri@stemsystems.com>
Re: bbs problem (Randal L. Schwartz)
Re: bbs problem <robin@csf.edu>
Re: bbs problem <uri@stemsystems.com>
Re: bbs problem <robin@csf.edu>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 22 Jan 2004 12:29:33 GMT
From: Joe Smith <Joe.Smith@inwap.com>
Subject: Re: bbs problem + using cgi
Message-Id: <NmPPb.103392$nt4.325983@attbi_s51>
Robin wrote:
> Here's what it looks like now, why isn't it printing it to the files...?
> use CGI qw(:standard);
> require ('lib.cgi');
> &data_cgivars;
Your main problem is that you can't use CGI and 'lib.cgi' in the
same program. The CGI module does everything that lib.cgi used
to do, the function calls and variable names have changed.
-Joe
--
I love my TiVo - http://www.inwap.com/u/joe/tivo/
------------------------------
Date: Thu, 22 Jan 2004 12:48:43 -0700
From: "Robin" <robin@csf.edu>
Subject: Re: bbs problem + using cgi
Message-Id: <bupacl$38d$2@reader2.nmix.net>
"Joe Smith" <Joe.Smith@inwap.com> wrote in message
news:NmPPb.103392$nt4.325983@attbi_s51...
> Robin wrote:
>
> > Here's what it looks like now, why isn't it printing it to the files...?
> > use CGI qw(:standard);
> > require ('lib.cgi');
> > &data_cgivars;
>
> Your main problem is that you can't use CGI and 'lib.cgi' in the
> same program. The CGI module does everything that lib.cgi used
> to do, the function calls and variable names have changed.
> -Joe
huh, it seemed to work using both of them...
I guess I'll just use cgi for the beta...peace,
-Robin
------------------------------
Date: Mon, 26 Jan 2004 05:10:26 GMT
From: Joe Smith <Joe.Smith@inwap.com>
Subject: Re: bbs problem + using cgi
Message-Id: <5j1Rb.116976$Rc4.921629@attbi_s54>
Robin wrote:
> "Joe Smith" <Joe.Smith@inwap.com> wrote in message
> news:NmPPb.103392$nt4.325983@attbi_s51...
>
>>Robin wrote:
>>
>>
>>>Here's what it looks like now, why isn't it printing it to the files...?
>>>use CGI qw(:standard);
>>>require ('lib.cgi');
>>>&data_cgivars;
>>
>>Your main problem is that you can't use CGI and 'lib.cgi' in the
>>same program. The CGI module does everything that lib.cgi used
>>to do, the function calls and variable names have changed.
>>-Joe
>
>
> huh, it seemed to work using both of them...
You *CANNOT* use both and have competent programming.
There are many examples of incompetent programming that "appear"
to work, but are extremely flawed.
When you actually use CGI.pm, it means a lot more than simply
putting 'use CGI' in your program. It means using the methods
and functions that come with that module. In particular, it
means replacing home-grown routines that print "Content-type:"
with routines that provide a full and proper set of HTML headers.
If you were really using CGI, you would not have a call
to data_cgivars().
-Joe
--
I love my TiVo - http://www.inwap.com/u/joe/tivo/
------------------------------
Date: Mon, 26 Jan 2004 07:50:35 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: bbs problem + using cgi
Message-Id: <bv2d9v$nk4ka$1@ID-184292.news.uni-berlin.de>
Joe Smith wrote:
> When you actually use CGI.pm, it means a lot more than simply
> putting 'use CGI' in your program. It means using the methods and
> functions that come with that module.
It should be noted that very few people choose to use everything that
comes with the giant CGI module.
> In particular, it means replacing home-grown routines that print
> "Content-type:" with routines that provide a full and proper set of
> HTML headers.
Well, CGI.pm abstracts quite a few trivial things without cause. It
may be a few more characters to type:
print "Content-type: text/html\n\n";
compared to:
print $query->header;
but printing the header directly has a pedagogic advantage, since you
learn what it looks like and are more likely to find out _why_ it's
printed. Prompting beginners not to do that is ill-advised IMO.
> If you were really using CGI, you would not have a call to
> data_cgivars().
Okay, on _that_ we can agree. ;-)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 26 Jan 2004 15:43:02 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: bbs problem + using cgi
Message-Id: <bv390q$ne1hu$1@ID-184292.news.uni-berlin.de>
Alan J. Flavell wrote:
> On Mon, 26 Jan 2004, Gunnar Hjalmarsson wrote:
>> Well, CGI.pm abstracts quite a few trivial things without cause.
>> It may be a few more characters to type:
>>
>> print "Content-type: text/html\n\n";
>>
>> compared to:
>>
>> print $query->header;
>
> Except that the second one will (at least by default in recent
> CGI.pm versions) follow the good practice recommended by security
> alert CA-2000-02, irrespective of whether the script author is
> aware of this recommendation or not.
Okay, it was kind of embarrassing to miss the charset in that example. ;-)
But is there really security considerations behind CGI.pm's default
setting of a character set? Isn't the reason rather to simply increase
the chances that the script generates valid HTML/XHTML?
The document you refer to addresses security issues in connection with
generated web content. But by referring to it in connection with a
discussion whether it's advisable to use CGI.pm for generating HTTP
headers, I think you make the mistake to give the impression that
CGI.pm takes care of all sorts of security issues. Unfortunately, a
lot of comments in this group about CGI contribute erroneously to that
impression.
Security is a good reason to learn enough to understand what you are
doing when dealing with CGI, rather than a reason to apply CGI.pm's
high degree of abstraction.
> Ideally, one would do both: learn what's happening under the
> covers, _and_ use CGI.pm at the core of production CGI code.
Maybe.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 26 Jan 2004 17:33:39 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: bbs problem + using cgi
Message-Id: <Pine.LNX.4.53.0401261712440.31392@ppepc56.ph.gla.ac.uk>
On Mon, 26 Jan 2004, Gunnar Hjalmarsson wrote:
> But is there really security considerations behind CGI.pm's default
> setting of a character set?
My recollection is that it was introduced in response to CA-2000-02,
although he doesn't say so in so many words in the change log.
However, Google will find some security-related discussions in Feb.
2000 about CGI.pm which followed from the alert (and the amended
Apache version).
IIRC it was introduced in CGI.pm 2.57 (deceased) and released in
CGI.pm 2.58 dated 23-Mar-2000.
CA-2000-02 is dated 2 Feb 2000. This is no mere co-incidence.
How many programmers fixed their hand-crafted scripts within that
space of time?
> The document you refer to addresses security issues in connection with
> generated web content.
It's a complex issue. I'm aware of other places where the use of
CGI.pm by default takes care of security-relevant mistakes which users
regularly make in hand-knitted code.
> But by referring to it in connection with a
> discussion whether it's advisable to use CGI.pm for generating HTTP
> headers, I think you make the mistake to give the impression that
> CGI.pm takes care of all sorts of security issues.
If that is so, then I would emphatically like to dispel that
impression. It does take care of some issues, but by no means does it
replace many other precautions that need to be taken for secure and
reliable scripts. Its author, after all, maintains a web security
FAQ, and that FAQ says much more than simply "use the module, Luke".
And rightly so.
------------------------------
Date: Mon, 26 Jan 2004 20:01:38 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: bbs problem + using cgi
Message-Id: <bv3o6c$nck1d$1@ID-184292.news.uni-berlin.de>
Alan J. Flavell wrote:
> [CGI.pm's] author, after all, maintains a web security FAQ, and
> that FAQ says much more than simply "use the module, Luke".
Yes, it does. I just wish that also those, who frequently prompt
beginners to use CGI.pm, would say more.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 26 Jan 2004 20:07:56 -0000
From: "gnari" <gnari@simnet.is>
Subject: Re: bbs problem + using cgi
Message-Id: <bv3s8f$j4c$1@news.simnet.is>
"Gunnar Hjalmarsson" <noreply@gunnar.cc> wrote in message
news:bv3o6c$nck1d$1@ID-184292.news.uni-berlin.de...
> Alan J. Flavell wrote:
> > [CGI.pm's] author, after all, maintains a web security FAQ, and
> > that FAQ says much more than simply "use the module, Luke".
>
> Yes, it does. I just wish that also those, who frequently prompt
> beginners to use CGI.pm, would say more.
beginners aready have enough to worry about.
as they advance in skills and knowledge, they can study
the modules they rely the most on, but mainly to be more
aware of what is going on. only when they have mastered
the art of reading the perldocs and faqs, should they go on
to learn to read the HTTP specs.
gnari
------------------------------
Date: Wed, 21 Jan 2004 14:48:19 -0000
From: "David K. Wall" <dwall@fastmail.fm>
Subject: Re: bbs problem
Message-Id: <Xns947763BEDA030dkwwashere@216.168.3.30>
Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "R" == Robin <robin@csf.edu> writes:
>
> R> Got it working...thanks for all your great help...
>
> got what working? your code had multiple bugs, security loopholes,
> redundant cruft (CGI.pm AND lib.cgi???? do you wear a belt and
> suspenders?), bad perl code, perl4 type calls, etc.
>
> no one here will use this and given the many (mostly crappy) free bbs
> things out there, this will only join that pile and rot away.
Yeah, I wrote one, too, several years ago. I suppose I should take it off
the web. The main reason I don't is because the page has links to a taint
mode FAQ and a perl.com article about free CGI resources that recommends
nms scripts. At least my crappy BBS uses strict, warnings, taint mode,
CGI.pm, and *tries* to be secure and easily maintainable. But it still
sucks....
After I tried writing one I found that I dislike web BBSs. Someone
mentioned perlmonks as a good place to learn. I'm sure it is, but web BBSs
-- all of them I've seen, anyway -- have such horrible interfaces. "Whip
me, beat me, make me write programs with Notepad and use a web BBS!"
--
David Wall
------------------------------
Date: Wed, 21 Jan 2004 16:26:22 +0100
From: Karlheinz Weindl <karlheinz.weindl@oooonlinehome.de>
Subject: Re: bbs problem
Message-Id: <bum5r0$b1p$1@online.de>
A. Sinan Unur schrieb:
> Karlheinz Weindl <karlheinz.weindl@oooonlinehome.de> wrote in
> news:bulcgt$4ed$1@online.de:
>
>
>>Gunnar Hjalmarsson wrote:
>>
>>>A. Sinan Unur wrote:
>>>
>>>
>>>>use CGI;
>>>>my $q = CGI->new();
>>>>
>>>>$CGI::POST_MAX=1024 * 100; # max 100K posts
>>>>$CGI::DISABLE_UPLOADS = 1; # no uploads
>>>
>>>
>>>Aren't those variables supposed to be set before the CGI object is
>>>created?
>>
>>That should not make any difference since this is class data.
>
>
> But sir, CGI.pm does the actual reading of the data when the first CGI
> object is created.
>
> Consider the following script:
>
> #! /usr/bin/perl -T
>
> use warnings;
> use strict;
>
> use CGI;
> my $q = CGI->new();
>
> $CGI::POST_MAX = 1;
> $CGI::DISABLE_UPLOADS = 1;
>
> unless($q->param('submit')) {
> show_form($q);
> } else {
> process_form($q);
> }
>
> sub show_form {
> my ($q) = @_;
> print $q->header();
> print <<HTML;
> <html>
> <body>
> <form method="post">
> <input type="hidden" name="hidden" value="0123456789">
> <input type="submit" name="submit" value="Submit">
> </form>
> </body>
> </html>
> HTML
> }
>
> sub process_form {
> my ($q) = @_;
> print $q->header();
> print <<HTML;
> <html>
> <body>
> <p>Hi</p>
> </body>
> </html>
> HTML
> }
>
> __END__
>
So, what am I supposed see running this?
Definitely not the submit button and the 'Hi'.
Karlheinz
------------------------------
Date: 21 Jan 2004 15:59:32 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude>
Subject: Re: bbs problem
Message-Id: <Xns94776FD264D48asu1cornelledu@132.236.56.8>
Karlheinz Weindl <karlheinz.weindl@oooonlinehome.de> wrote in news:bum5r0
$b1p$1@online.de:
> A. Sinan Unur schrieb:
>
>> Karlheinz Weindl <karlheinz.weindl@oooonlinehome.de> wrote in
>> news:bulcgt$4ed$1@online.de:
>>
>>
>>>Gunnar Hjalmarsson wrote:
>>>
>>>>A. Sinan Unur wrote:
>>>>
>>>>
>>>>>use CGI;
>>>>>my $q = CGI->new();
>>>>>
>>>>>$CGI::POST_MAX=1024 * 100; # max 100K posts
>>>>>$CGI::DISABLE_UPLOADS = 1; # no uploads
>>>>
>>>>
>>>>Aren't those variables supposed to be set before the CGI object is
>>>>created?
>>>
>>>That should not make any difference since this is class data.
>>
>>
>> But sir, CGI.pm does the actual reading of the data when the first CGI
>> object is created.
>>
>> Consider the following script:
>>
...
>> use CGI;
>> my $q = CGI->new();
>>
>> $CGI::POST_MAX = 1;
>> $CGI::DISABLE_UPLOADS = 1;
...
> So, what am I supposed see running this?
> Definitely not the submit button and the 'Hi'.
If you set the variables after creating the CGI object (as above), that is
exactly what you are going to see. Whereas if you set the variables before
creating the CGI object, you will see the submit button again.
Noe that I have removed the ctest_after script from my site because I do
not have a built in vulnerability advertised on the UseNet on my site.
You'll have to try the to versions out and see for yourself.
In fact, if you could be bothered to check the source code for CGI.pm
before posting assertions and challenges, you will see that content length
is only checked and STDIN only read in init and only if the CGI has not yet
been initialized. So setting the variables above after you have created the
first CGI object is futile.
This will hopefully be my last communication with you on this topic.
--
A. Sinan Unur
1usa@llenroc.ude (reverse each component for email address)
------------------------------
Date: Wed, 21 Jan 2004 18:36:52 +0100
From: Karlheinz Weindl <karlheinz.weindl@oooonlinehome.de>
Subject: Re: bbs problem
Message-Id: <bumdfl$qro$1@online.de>
A. Sinan Unur wrote:
[...]
>>>use CGI;
>>>my $q = CGI->new();
>>>
>>>$CGI::POST_MAX = 1;
>>>$CGI::DISABLE_UPLOADS = 1;
>
>
> ...
>
>
>
>>So, what am I supposed see running this?
>>Definitely not the submit button and the 'Hi'.
>
>
> If you set the variables after creating the CGI object (as above), that is
> exactly what you are going to see. Whereas if you set the variables before
> creating the CGI object, you will see the submit button again.
Sorry, did not mean to annoy you. I just did not get your point of
restricting the POST size to 1 byte at a first glance.
[...]
> This will hopefully be my last communication with you on this topic.
Probably next time I should post under the pseudonym 'Robin' to receive
a less harsh tone from your side :)
bye
Karlheinz
------------------------------
Date: 21 Jan 2004 17:56:59 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude>
Subject: Re: bbs problem
Message-Id: <Xns947783BC3DCCEasu1cornelledu@132.236.56.8>
Karlheinz Weindl <karlheinz.weindl@oooonlinehome.de> wrote in
news:bumdfl$qro$1@online.de:
> A. Sinan Unur wrote:
>
>> If you set the variables after creating the CGI object (as above),
>> that is exactly what you are going to see. Whereas if you set the
>> variables before creating the CGI object, you will see the submit
>> button again.
>
> Sorry, did not mean to annoy you. I just did not get your point of
> restricting the POST size to 1 byte at a first glance.
>
> [...]
>> This will hopefully be my last communication with you on this topic.
>
> Probably next time I should post under the pseudonym 'Robin' to
> receive a less harsh tone from your side :)
OK, I admit that was a little over the top. Apologies. No need to sink to
those lows :)
Sinan.
--
A. Sinan Unur
1usa@llenroc.ude (reverse each component for email address)
------------------------------
Date: Wed, 21 Jan 2004 17:41:54 -0700
From: "Robin" <robin@csf.edu>
Subject: Re: bbs problem
Message-Id: <bun79f$to1$1@reader2.nmix.net>
>
> I do not see at the moment how you are protecting against the
> possibility that someone might deliberately include html in their
> posting. You seem to take in whatever the user sent, and output it
> directly. So if someone puts in <blink>Hi, mom!</blink> then you'd
> output exactly that and the browsers are going to react to it.
> Even if it's javascript or if the user included </form> and
> started a new <form> and so on.
>
> : if ($FORM{'name'} && $FORM{'email'} && $FORM{'post'} && $FORM{'name1'}
!~
> :/\./ && $FORM{'name'} !~ /<.*>/ && $FORM{'email'} !~ /<.*>/ &&
$FORM{'post'}
> :!~ /<.*>/ && $FORM{'name'} !~ /^\s*$/ && $FORM{'email'} !~ /^\s*$/ &&
> :$FORM{'post'} !~ /^\s*$/)
>
> I see there that you do match $FORM{'post'} against /<.*>/ but
> that is not going to work if the string has embeded newlines.
> You would need /<.*>/s for that case. (The s modifier is not
> available in perl4 though.)
Thanks for this and thanks for the email, I'll actually get that code fixed
so its less of a security loop....
-Robin
------------------------------
Date: Thu, 22 Jan 2004 12:24:01 GMT
From: Joe Smith <Joe.Smith@inwap.com>
Subject: Re: bbs problem
Message-Id: <BhPPb.124434$na.125939@attbi_s04>
Robin wrote:
>>>require ('lib.cgi');
Bad idea.
>>use CGI;
>>my $q = CGI->new();
Good idea.
> How would I do this without using cgi?
Why would you want to avoid CGI.pm?
Oh, I see:
Post - Welcome to the Perl 4 Beginners BBS
The world does *NOT* need any more Perl 4 Beginners.
Perl 5 came out at the end of 1994. That's almost
ten years! Come on, Robin, get with the program!
Learn to use perl 5. Your life will be better for it.
-Joe
--
I love my TiVo - http://www.inwap.com/u/joe/tivo/
------------------------------
Date: Thu, 22 Jan 2004 12:47:24 -0700
From: "Robin" <robin@csf.edu>
Subject: Re: bbs problem
Message-Id: <bupack$38d$1@reader2.nmix.net>
> Robin wrote:
>
> >>>require ('lib.cgi');
>
> Bad idea.
>
> >>use CGI;
> >>my $q = CGI->new();
>
> Good idea.
>
> > How would I do this without using cgi?
>
> Why would you want to avoid CGI.pm?
>
> Oh, I see:
> Post - Welcome to the Perl 4 Beginners BBS
It was supposed to say perl4beginners-I do use perl 5 if you really have to
know. I wanted to use my library because I still dunno how to work CGI.pm,
but I'm learning it.
> The world does *NOT* need any more Perl 4 Beginners.
>
> Perl 5 came out at the end of 1994. That's almost
> ten years! Come on, Robin, get with the program!
> Learn to use perl 5. Your life will be better for it.
> -Joe
peace,
-Robin
------------------------------
Date: Thu, 22 Jan 2004 20:05:20 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: bbs problem
Message-Id: <x7k73j7nr4.fsf@mail.sysarch.com>
>>>>> "R" == Robin <robin@csf.edu> writes:
R> It was supposed to say perl4beginners-I do use perl 5 if you really
R> have to know. I wanted to use my library because I still dunno how
R> to work CGI.pm, but I'm learning it.
that is pathetic. your lib is HARDER to use than cgi.pm. cgi.pm has to
be one of the easiest to use modules in existance given the complexity
of what goes on behind the curtain.
please take up some other hobby. programming is not for you. do you
realize how much you don't know and at the rate you seem to absorb stuff
you might be able to code on your own in 30 years.
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: Thu, 22 Jan 2004 21:54:38 GMT
From: merlyn@stonehenge.com (Randal L. Schwartz)
To: "Robin" <robin@csf.edu>
Subject: Re: bbs problem
Message-Id: <5b0d731529f5c9e70f02479572758dd4@news.teranews.com>
>>>>> "Robin" == Robin <robin@csf.edu> writes:
Robin> It was supposed to say perl4beginners-I do use perl 5 if you
Robin> really have to know. I wanted to use my library because I still
Robin> dunno how to work CGI.pm, but I'm learning it.
Really? How tough is it to learn this:
use CGI qw(param);
my $name = param('name'); # get param field named 'name'
my @options = param('options'); # get multi-field (all values)
That's *it*. That's all you need to know about CGI.pm and you can
throw away *everything* you've seen from the Perl4 days. Really. You
can. You can do it. You don't have to use any of the other shortcut
things, or sticky fields, or anything else. Just please please please
use CGI.pm to read the params in a portable, safe fashion.
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: Thu, 22 Jan 2004 15:43:09 -0700
From: "Robin" <robin@csf.edu>
Subject: Re: bbs problem
Message-Id: <bupkmt$681$1@reader2.nmix.net>
> please take up some other hobby.
yeah well... maybe if you didn't post at all you'd be coding on your own...
:-)
-Robin
------------------------------
Date: Thu, 22 Jan 2004 23:11:55 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: bbs problem
Message-Id: <x74qun7f44.fsf@mail.sysarch.com>
>>>>> "R" == Robin <robin@csf.edu> writes:
>> please take up some other hobby.
R> yeah well... maybe if you didn't post at all you'd be coding on your own...
i code plenty as it is. i also read and think plenty too. that is the
difference between my work and the scribbling you do. you have
reinvented many wheels and they come out very square.
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: Thu, 22 Jan 2004 18:59:06 -0700
From: "Robin" <robin@csf.edu>
Subject: Re: bbs problem
Message-Id: <buq031$9jd$1@reader2.nmix.net>
> >> please take up some other hobby.
>
> R> yeah well... maybe if you didn't post at all you'd be coding on your
own...
>
> i code plenty as it is. i also read and think plenty too. that is the
> difference between my work and the scribbling you do. you have
> reinvented many wheels and they come out very square.
>
> uri
>
Yeah well, I read a lot of non-tech stuff and some tech, but probably not as
much as you...I think, else how would I write code at all even if I my code
sucks, don't mean to be overtly defensive... peace,
-Robin
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 5998
***************************************
