[29519] in Perl-Users-Digest
Perl-Users Digest, Issue: 763 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 17 00:09:43 2007
Date: Thu, 16 Aug 2007 21:09:03 -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 Thu, 16 Aug 2007 Volume: 11 Number: 763
Today's topics:
Re: [OT] Dealing with spam (was: Perl On Apache) <stoupa@practisoft.cz>
Re: format/write question <jgibson@mail.arc.nasa.gov>
Re: format/write question <ddunham@redwood.taos.com>
Re: havoing trouble with text substitution <stoupa@practisoft.cz>
Re: Help: How to use filehandle to save files? <openlinuxsource@gmail.com>
Re: Help: How to use filehandle to save files? <tadmc@seesig.invalid>
Re: How to get "<$myclass_instance>" to work? <jgibson@mail.arc.nasa.gov>
Re: Replacing Print Location.. <jgibson@mail.arc.nasa.gov>
Re: Replacing Print Location.. <bill@ts1000.us>
use WWW::Mechanize to tick one or more checkbox? <jck11@chia01.tachia.gov.tw>
Re: Using Subroutines with CGI::Session::MySQL? <paduille.4061.mumia.w+nospam@earthlink.net>
Re: Using Subroutines with CGI::Session::MySQL? xhoster@gmail.com
Re: Using Subroutines with CGI::Session::MySQL? <ljames@apollo3.com>
Re: Using Subroutines with CGI::Session::MySQL? <ljames@apollo3.com>
Re: Using Subroutines with CGI::Session::MySQL? xhoster@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 17 Aug 2007 01:48:45 +0200
From: "Petr Vileta" <stoupa@practisoft.cz>
Subject: Re: [OT] Dealing with spam (was: Perl On Apache)
Message-Id: <fa2p31$9fj$1@ns.felk.cvut.cz>
Martijn Lievaart wrote:
> On Sat, 11 Aug 2007 05:55:17 +0200, Gunnar Hjalmarsson wrote:
>
>> Petr Vileta wrote:
>>> (My server rejects all messages from Yahoo and Hotmail.
>>
>> Funny; I get almost no spam from Yahoo or Hotmail servers.
>
> Neither do I. But I reject all mail from hotmail, so othat figures.
>
>> Or are you saying that you reject messages based on the faked From
>> addresses??
>
> I both reject any message with a hotmail "mail from" and all messages
> from hotmails servers.
>
I reject many other mails by IP address or IP ranges. If you want to have my
blacklist you can download it from
http://www.practisoft.cz/download/blacklist.zip
At the begin I have section called "idiots list". In this section are unique
IPs of people who have PC infected frequently (idiots) :-)
Maybe this name (idiots list) will come new standard term. We have
white-list, black-list, shadow-list. Why not idiots-list? :-)
--
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)
------------------------------
Date: Thu, 16 Aug 2007 15:57:17 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: format/write question
Message-Id: <160820071557178692%jgibson@mail.arc.nasa.gov>
In article <5ijdueF3p2qmfU1@mid.individual.net>, Steve K.
<savagebeaste@yahoo.com> wrote:
> I seem to be having a difficult time understanding formats.
[snip]
>
> I'm also wondering why one would want to use them over printf/sprintf,
> especially when they seem to be so much trouble to use. It reminds me a
> little of Cobol.
In 10 years of Perl programming, I have never used formats. I would
guess that the majority of Perl programmers would say the same. I just
use printf.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
Date: Thu, 16 Aug 2007 23:43:22 GMT
From: Darren Dunham <ddunham@redwood.taos.com>
Subject: Re: format/write question
Message-Id: <ui5xi.49769$YL5.46140@newssvr29.news.prodigy.net>
Steve K. <savagebeaste@yahoo.com> wrote:
> #!/usr/local/bin/perl
> use strict;
> our $text = "line 1\nline 2\nline 3";
> format STDOUT =
> Text: ^*
> $text
> ~~ ^*
> $text
> .
> write (STDOUT);
I don't see in the 5.6.1 documentation that ^* is supported. So it's
either not supposed to work in older versions, or it wasn't much used
and you've found an old bug.
99% of the formats I've seen and used just worked with simple
fixed-width fields.
> I'm also wondering why one would want to use them over printf/sprintf,
> especially when they seem to be so much trouble to use. It reminds me a
> little of Cobol.
Maybe you don't. But formats do understand line counts per page, so if
you're used to 66 line pages, they take a bit of work out. You'd have
to code some extra logic to do that with printf.
--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
------------------------------
Date: Fri, 17 Aug 2007 01:55:17 +0200
From: "Petr Vileta" <stoupa@practisoft.cz>
Subject: Re: havoing trouble with text substitution
Message-Id: <fa2p38$9fj$2@ns.felk.cvut.cz>
pauls wrote:
> I am trying to find any text in a file with the following characters
> in it:
> r+c.mod
>
> and doing a substitution as follows:
>
>
> s'r+c.mod'D:/spice/r+c.mod';
>
> but, for some reason (tell me what I am doing wrong please) PERL
> cannot find the instances of r+c
>
You must escape + and . characters. Maybe you can use this
s#(r\+c\.mod)#D:/spice/$1#;
Note: I rather use # as alternative parentheses. The apostrophe is bad
readable for my eyes ;-)
--
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)
------------------------------
Date: Fri, 17 Aug 2007 08:03:52 +0800
From: Amy Lee <openlinuxsource@gmail.com>
Subject: Re: Help: How to use filehandle to save files?
Message-Id: <pan.2007.08.17.00.03.52.411459@gmail.com>
Thank you everyone very much~
However, I still got a problem, why I must use use some variables to open
files? In my source code, I use
open EST, '<', $EST
to open a file.
If I use <EST> to operate this function, how can I save the files?
In my first post, there's my source code.
Thank you very much~
Regards,
Amy Lee
------------------------------
Date: Fri, 17 Aug 2007 02:15:20 GMT
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Help: How to use filehandle to save files?
Message-Id: <slrnfca0s8.jdd.tadmc@tadmc30.sbcglobal.net>
Amy Lee <openlinuxsource@gmail.com> wrote:
> However, I still got a problem, why I must use use some variables to open
> files?
I cannot understand your question.
> In my source code, I use
>
> open EST, '<', $EST
>
> to open a file.
>
> If I use <EST> to operate this function, how can I save the files?
By print()ing to some other filehandle.
open my $OUT, '>', "${EST}_format" or
die "could not open '${EST}_format for output $!";
while ( <EST> ) {
# do stuff to $_
print {$OUT};
}
close $OUT;
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Thu, 16 Aug 2007 15:52:18 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: How to get "<$myclass_instance>" to work?
Message-Id: <160820071552180750%jgibson@mail.arc.nasa.gov>
In article <fa1qpu$imt$1@reader1.panix.com>, kj
<socyl@987jk.com.invalid> wrote:
> I want to write a class whose instances are iterators that will
> behave similarly to (readonly) file handles. I.e. I want to be
> able to write:
>
> my $thingie = Thingie->new( @args );
> while ( <$thingie> ) {
> # do stuff with $_
> }
>
> Can someone point me to a good example of a module in CPAN that
> does this, for me to study? I'm looking specifically for a module
> that achieves this functionality via standard Perl subclassing (as
> opposed to tied variables, which I find too magic and mysterious).
Why don't you just use a normal method?:
my $thingie = Thingie->new( @args );
while( $_ = $thingie->next() ) {
# do stuff with $_
}
and implement next() appropriately.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
Date: Thu, 16 Aug 2007 16:16:01 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: Replacing Print Location..
Message-Id: <160820071616016125%jgibson@mail.arc.nasa.gov>
In article <1187288663.883215.18030@w3g2000hsg.googlegroups.com>, Bill
H <bill@ts1000.us> wrote:
> I have a perl script that process form inputs, saves the data and then
> does a "print location: ..." to a different perl program that creates
> pdf files from the saved data (using data passed in the url), and when
> its done it does a "print location ..." to get back to the 1st
> program. All these programs are on the same server and in the same
> folder. The reason for 2 programs is that the the 2nd one loads a
> number of support libraries for creating pdf's, handling images etc,
> the 1st one is basically a form processor and information controller.
> Instead of using this method, can I use an exec call? Would the
> initial environment variables still be there?
I am not proficient in HTTP, but it sounds to me as if you are
returning a Location response to the web browser from the first
submission, which requires the browser to send a second HTTP request to
your second program (I don't believe the server will figure out that
the Location redirect is to itself), which returns a Location response
to the browser, which then sends a third HTTP request to the server to
the first script. Right?
Why don't you just combine the two programs and save two rounds of
request-response.
--
Jim Gibson
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
Date: Thu, 16 Aug 2007 17:15:57 -0700
From: Bill H <bill@ts1000.us>
Subject: Re: Replacing Print Location..
Message-Id: <1187309757.321463.151100@g4g2000hsf.googlegroups.com>
On Aug 16, 7:16 pm, Jim Gibson <jgib...@mail.arc.nasa.gov> wrote:
> In article <1187288663.883215.18...@w3g2000hsg.googlegroups.com>, Bill
>
> H <b...@ts1000.us> wrote:
> > I have a perl script that process form inputs, saves the data and then
> > does a "print location: ..." to a different perl program that creates
> > pdf files from the saved data (using data passed in the url), and when
> > its done it does a "print location ..." to get back to the 1st
> > program. All these programs are on the same server and in the same
> > folder. The reason for 2 programs is that the the 2nd one loads a
> > number of support libraries for creating pdf's, handling images etc,
> > the 1st one is basically a form processor and information controller.
> > Instead of using this method, can I use an exec call? Would the
> > initial environment variables still be there?
>
> I am not proficient in HTTP, but it sounds to me as if you are
> returning a Location response to the web browser from the first
> submission, which requires the browser to send a second HTTP request to
> your second program (I don't believe the server will figure out that
> the Location redirect is to itself), which returns a Location response
> to the browser, which then sends a third HTTP request to the server to
> the first script. Right?
>
> Why don't you just combine the two programs and save two rounds of
> request-response.
>
> --
> Jim Gibson
>
> Posted Via Usenet.com Premium Usenet Newsgroup Services
> ----------------------------------------------------------
> ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
> ----------------------------------------------------------
> http://www.usenet.com
Jim
Thats exactly what it is doing. The reason for not combining them is
the middle program uses a lot of libraries to build pdf files and
process images. This is a lot of overhead I don't need in the other
program which is basically a form handler that saves data in a
particular file based on the user (well it does a lot of other web
based stuff). I suppose I could eliminate the 1st call by including
the data saving in the middle program and then it would only be 2
"Print Location"s.
What I would like best is to do something that I used to do back in my
Basic programming days on CP/M machines, when done with one program,
chain to another and have the variables stay intact. In the case of
Perl I would just want to be able to access the same Env values that
the 1st program that was called by the user access (ie form data,
cookies etc) in place of the variables staying intact as was done on
the old Basic programs.
I hope this makes since.
Bill H
------------------------------
Date: Fri, 17 Aug 2007 09:17:42 +0800
From: "jck11" <jck11@chia01.tachia.gov.tw>
Subject: use WWW::Mechanize to tick one or more checkbox?
Message-Id: <fa2t40$543$1@netnews.hinet.net>
Hi all
My html look like
<INPUT type="checkbox" name="aaa" value="111" id="id111">
<INPUT type="checkbox" name="aaa" value="222" id="id222">
..
<INPUT type="checkbox" name="aaa" value="999" id="id999">
How can I use WWW::Mechanize to tick one or more checkbox?
A peice of code of mime:
=========================================================
$mech->form_number(1);
my $name='aaa';
my $value=$mech->value($name);
$value='undef' unless defined $value;
print "[1] value for $name: ($value)\n";
$mech->tick($name, $value);
$value=$mech->value($name);
$value='undef' unless defined $value;
print "[2] value for $name: ($value)\n";
=========================================================
and get the result:
---------------------------------------------------------
[1] value for aaa: (undef)
No checkbox "aaa" for value "undef" in form at test.pl line 56
[2] value for aaa: (undef)
---------------------------------------------------------
change the code to:
=========================================================
$mech->form_number(1);
my $name='aaa';
my $value='111';
$mech->tick($name, $value);
$value=$mech->value($name);
$value='undef' unless defined $value;
print "[2] value for $name: ($value)\n";
=========================================================
and get the result:
---------------------------------------------------------
[2] value for aaa: (undef)
---------------------------------------------------------
It seems don't work this way.
Any suggestion?
------------------------------
Date: Thu, 16 Aug 2007 17:42:34 -0500
From: "Mumia W." <paduille.4061.mumia.w+nospam@earthlink.net>
Subject: Re: Using Subroutines with CGI::Session::MySQL?
Message-Id: <13c9kpipa23pvcb@corp.supernews.com>
On 08/16/2007 01:14 PM, L. D. James wrote:
> On Aug 16, 1:07 pm, xhos...@gmail.com wrote:
>
>> In a mod_perl environment, the $session that is accessible from inside
>> processdata is the variable allocated when the code was compiled, which
>> means it is the variable that was in effect the first time this
>> particular apache process invoked this code. So on subsequent invocation,
>> $session outside of processdata is a new $session, while inside of
>> processdata you get some earlier $session.
>>
>> This is part of the "variable will not stayed shared" problem. One
>> fix is to pass $session into the subroutine rather than using the one
>> from the outer scope:
>>
>> sub processdata {
>> my $session=shift;
>> #...
>>
>> };
>>
>> Xho
>>
>> --
>> --------------------http://NewsReader.Com/--------------------
>> Usenet Newsgroup Service $9.95/Month 30GB
>
> Thanks, Xho, for the input. I tested you fix and it works in the
> example. I was actually in the process of changing from the File
> driver to the MySQL driver. I have 10's of subroutines that update or
> check the session data before exiting. Many of the subroutines have
> been accumulated almost like a library of utilities that has expected
> parameters, which I've been reusing (and refining) for years.
>
> You are the second person that suggests that the mod_perl environment
> might be a culprit. Is there a way to instruct the program to use the
> regular perl rather than mod_perl.
>
Whether mod_perl or Perl/CGI is used is determined by the Apache
configuration.
> Do you know why this additional parameter passing isn't required with
> using the File driver? As much as I would have preferred to move over
> to the mysql driver, I may have to hold off, for having to add a new
> expected parameter to all my modules.
>
Xhoster got it right, and that's pretty good because the problem is
confusing. It evidently has something to do with the way that
processdata is compiled. Even this causes the bug to appear:
sub processdata()
{
my $username = 'No Data Yet';
print "<br>-->$name<--<br>-->$count<--<br>";
if (0) { $username = $session->param('f_name') }
print "<br>Processing Data for $username.<br>";
};
> By the way, reading the data from any of the subroutines is never a
> problem. The problem is that the session info can't be updated from
> anywhere, not even the main program if the line:
>
> $session->param('anyparam');
>
> is referenced in any subroutine, even if that subroutine isn't called.
>
Yes.
> You can test that by commenting out the $session->param('f_name');
> line from my example script.
>
> Maybe I'm looking for a way to make the $session data more public. Or
> maybe, possibly adding some variant of
>
Or perhaps less public (see below).
> $session = new CGI::Session("driver:MySQL", $sid, {Handle=>$dbh}) or
> die "Session Error...";
>
> to each subroutine that needs to access the session data.
>
> Thanks again for the input.
>
> -- L. James
The problem is fixed if you "undef" the $session variable after you're
finished with it. Place this at the bottom of your program:
undef $session;
Remember that mod_perl creates persistent interpreters. The variables
and data in those interpreters can live for much longer than you expect
if you're accustomed to Perl/CGI.
I guess that any variables that you don't specifically want to remain
around until the web server shuts down should be explicitly "undef-ed."
------------------------------
Date: 17 Aug 2007 00:12:41 GMT
From: xhoster@gmail.com
Subject: Re: Using Subroutines with CGI::Session::MySQL?
Message-Id: <20070816201244.859$3D@newsreader.com>
"L. D. James" <ljames@apollo3.com> wrote:
>
> You are the second person that suggests that the mod_perl environment
> might be a culprit. Is there a way to instruct the program to use the
> regular perl rather than mod_perl.
That is an apache configuration issue. On the configuration that came with
my machine, scripts in /var/www/cgi-bin/ run by traditional CGI and scripts
in /var/www/perl/ run with mod_perl. Your configuration will be different.
> Do you know why this additional parameter passing isn't required with
> using the File driver?
I don't know. Perhaps it is a problem, and just has never presented itself
in an obvious way. Anyway, I would certainly consider it a problem waiting
to happen, and would be uneasy with just sticking with the file method
on the assumption that it is working correctly. My gut feeling is that
occasionally people are pulling data out of other people's session files,
which could be disastrous in a subtle way.
> As much as I would have preferred to move over
> to the mysql driver, I may have to hold off, for having to add a new
> expected parameter to all my modules.
>
> By the way, reading the data from any of the subroutines is never a
> problem. The problem is that the session info can't be updated from
> anywhere, not even the main program if the line:
>
> $session->param('anyparam');
>
> is referenced in any subroutine, even if that subroutine isn't called.
The subroutine holds an implicit reference to $session (the first $session
that existed at the time the subroutine was compiled). Because the
subroutine is not lexical, it never goes out of scope, which means the
reference it holds to $session never goes away, and hence $session itself
never goes out of scope and gets cleaned up (in this case, the mysql
connection does not get closed). This is the case whether or not the
subroutine ever gets called.
I don't understand why this leads to the exact problem you are observing
(do you see any errors in the logs?) but once you are living in a state of
sin, all bets are off on the weird things that can happen.
Anyway, you should run under warnings, and you should check your error logs
for those warnings. I get warnings that 'variable "$session" will not stay
shared' when I do things like that, and these warnings should not be
ignored.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Thu, 16 Aug 2007 17:26:24 -0700
From: "L. D. James" <ljames@apollo3.com>
Subject: Re: Using Subroutines with CGI::Session::MySQL?
Message-Id: <1187310384.568404.66800@r29g2000hsg.googlegroups.com>
On Aug 16, 6:42 pm, "Mumia W." <paduille.4061.mumia.w
+nos...@earthlink.net> wrote:
>
> The problem is fixed if you "undef" the $session variable after you're
> finished with it. Place this at the bottom of your program:
>
> undef $session;
>
> Remember that mod_perl creates persistent interpreters. The variables
> and data in those interpreters can live for much longer than you expect
> if you're accustomed to Perl/CGI.
>
> I guess that any variables that you don't specifically want to remain
> around until the web server shuts down should be explicitly "undef-ed."
Bingo!
Works like a charm.
The "package Experimental" worked on the sample code, but failed when
used in conjunction with the full program that has many subroutines.
The passing of the $session couldn't be used because all the
subroutines would have to be rewritten to take a new parameter into
effect. Also, some of the routines would call some of the common
subroutines that didn't have a $session parameter to send. But the
concept gave me a lot of insight to study.
My resolution to make $sid a public variable and create a "new
CGI::Session" in each subroutine that needed to access the sessions
appeared to be workable. That's what I had been doing between looking
at your last input.
The "undef $session" worked immediately on the full program without
any changes. Your discussion about the left over garbage answered
another question that I had been trying to figure out a good way of
asking.
I had been wondering if perl leaked, and how much cleanup it did when
exiting the application from a subroutine without doing cleanup.
All my fill access programs close the file handle before exiting
perl. However, many of my mysql programs exited out the subroutine
when it finished doing its job, thereby often never reaching the $dbh-
disconnect() at the end of the code. This is especially the case
where my code reaches an error. I display a message then exits. I'm
sure, by the way, that the "die" function does some cleanup. As far
as all my other routines, I'm updating them to go to a "finish()"
subroutine to cleanup before exiting.
Thanks again for all the help and discussion. I had lost a night of
sleep trying to figure out what was going wrong.
-- L. James
--
L. D. James
ljames@apollo3.com
www.apollo3.com/~ljames
------------------------------
Date: Thu, 16 Aug 2007 17:50:54 -0700
From: "L. D. James" <ljames@apollo3.com>
Subject: Re: Using Subroutines with CGI::Session::MySQL?
Message-Id: <1187311854.759496.201050@d55g2000hsg.googlegroups.com>
Thanks, Xhoster. You're right about being concerned about something
that works one way and not working another being a possible game of
roulette... disaster waiting to happen. This is why I was so persistent
about finding a consistent solution and understanding as much as I
could about the functions and library.
I always use the warnings. The code using the File (or the MySQL
which failed) never produced any errors. However, I appreciate your
thoughts on doing robust checking to insure what's happening with the
data. It would be a serious security breach to pass the wrong data to
the wrong user. I'm still studying the CGI::Sessions Tutorials and
CookBook references to gain as much understanding as I can, and to be
sure to follow the examples of their models.
I'm surprised after all the reading I had been doing for a whole day I
missed the "undef $session" that's referenced in the documentation.
Looking further, I see a $session parameter in their sub routine
examples. So, as I mentioned in the previous message, I'm rewriting
my subroutines that uses the $sessions data to insure they follow the
proper design.
Thanks again for all the input and discussion.
-- L. James
--
L. D. James
ljames@apollo3.com
www.apollo3.com/~ljames
------------------------------
Date: 17 Aug 2007 01:18:24 GMT
From: xhoster@gmail.com
Subject: Re: Using Subroutines with CGI::Session::MySQL?
Message-Id: <20070816211828.259$pg@newsreader.com>
"L. D. James" <ljames@apollo3.com> wrote:
> Thanks, Xhoster. You're right about being concerned about something
> that works one way and not working another being a possible game of
> roulette... disaster waiting to happen. This is why I was so persistent
> about finding a consistent solution and understanding as much as I
> could about the functions and library.
>
> I always use the warnings. The code using the File (or the MySQL
> which failed) never produced any errors.
Are you sure you are looking in the right place?
I'd add something like this, which certainly should
produce warnings, to your code:
sub sdfsadf { my $x; sub alkj { $x }};
Should produce warnings like
Variable "$x" will not stay shared at -e line 1.
If you don't see messages corresponding to that, then you may
be looking in the wrong place. On your original code, I found
these warnings on $session, $name, and $count.
Also, with your code on my system under mod_perl (I have mod_perl 1, not
mod_perl 2) I see the non-update of the counter under the default file
driver.
> However, I appreciate your
> thoughts on doing robust checking to insure what's happening with the
> data. It would be a serious security breach to pass the wrong data to
> the wrong user. I'm still studying the CGI::Sessions Tutorials and
> CookBook references to gain as much understanding as I can, and to be
> sure to follow the examples of their models.
Those sources make very scant reference to mod_perl. If you are going to
run under mod_perl, you definitely need to read up on that, as well. The
problems you are seeing are due to way you are using mod_perl, and
related problems may well pop up in contexts other than CGI::Session as
well. Generally I just avoid mod_perl until I know for certain that
it is necessary.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
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 V11 Issue 763
**************************************
