[29486] in Perl-Users-Digest
Perl-Users Digest, Issue: 730 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Aug 8 14:19:25 2007
Date: Wed, 8 Aug 2007 11:19:15 -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 Wed, 8 Aug 2007 Volume: 11 Number: 730
Today's topics:
Re: Subroutines and '&' trudge@gmail.com
Re: Subroutines and '&' <mritty@gmail.com>
Re: Subroutines and '&' anno4000@radom.zrz.tu-berlin.de
Re: Subroutines and '&' anno4000@radom.zrz.tu-berlin.de
Re: Subroutines and '&' <mritty@gmail.com>
Re: Subroutines and '&' <m@rtij.nl.invlalid>
Re: Subroutines and '&' anno4000@radom.zrz.tu-berlin.de
Re: Subroutines and '&' <1usa@llenroc.ude.invalid>
Re: Subroutines and '&' <nospam@somewhere.com>
Re: Subroutines and '&' (Randal L. Schwartz)
Re: Subroutines and '&' <yankeeinexile@gmail.com>
Re: Subroutines and '&' trudge@gmail.com
Re: Subroutines and '&' trudge@gmail.com
Re: Subroutines and '&' trudge@gmail.com
windows perl modules <hara.acharya@gmail.com>
Re: windows perl modules <1usa@llenroc.ude.invalid>
Re: windows perl modules <stoupa@practisoft.cz>
Re: windows perl modules <bik.mido@tiscalinet.it>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 08 Aug 2007 02:05:07 -0700
From: trudge@gmail.com
Subject: Re: Subroutines and '&'
Message-Id: <1186563907.206979.98990@d55g2000hsg.googlegroups.com>
On Aug 7, 2:54 pm, mer...@stonehenge.com (Randal L. Schwartz) wrote:
> >>>>> "~greg" == ~greg <g...@remove-comcast.net> writes:
>
> ~greg> It is still required,
> ~greg> but only when dealing with references (I think)
>
> Or when dealing with a subroutine that is the same name as a built-in.
> See my other post.
>
In another situation, I find it most useful as well. For example, I
typically determine what to do in a script by checking an incoming
parameter of a form:
my $MODE=param('Mode');
{
no strict;
$MODE="GetLogin" unless $MODE; # default sub to execute
&$MODE; # else execute this sub
}
This saves a lot of 'if-else' chains. Just my 2 Canadian cents.
--
Amer Neely
Web Mechanic - www.webmechanic.softouch.on.ca
------------------------------
Date: Wed, 08 Aug 2007 03:39:13 -0700
From: Paul Lalli <mritty@gmail.com>
Subject: Re: Subroutines and '&'
Message-Id: <1186569553.379906.185950@r34g2000hsd.googlegroups.com>
On Aug 8, 5:05 am, tru...@gmail.com wrote:
> I
> typically determine what to do in a script by checking an incoming
> parameter of a form:
>
> my $MODE=param('Mode');
> {
> no strict;
> $MODE="GetLogin" unless $MODE; # default sub to execute
> &$MODE; # else execute this sub
>
> }
>
> This saves a lot of 'if-else' chains. Just my 2 Canadian cents.
It's also a rather absurdly large security whole. You have no way of
knowing what that parameter is. You are making the assumption that
the only way to contact your CGI script is via your form. This is
incorrect. A user can contact your CGI script without ever going near
your form.
You are allowing your users to call any subroutine in your program.
Paul Lalli
------------------------------
Date: 8 Aug 2007 10:42:00 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Subroutines and '&'
Message-Id: <5htkvoF3m6tjnU1@mid.dfncis.de>
John W. Krahn <krahnj@telus.net> wrote in comp.lang.perl.misc:
> Randal L. Schwartz wrote:
> >>>>>> "Sherm" == Sherm Pendley <spamtrap@dot-app.org> writes:
> >
> > Sherm> It *does* make a difference - if you don't know or understand what that
> > Sherm> difference is, or you don't specifically want the behavior specified by
> > Sherm> the &, you shouldn't use it.
> >
> > Or, for the opposite point of view, if you have:
> >
> > sub log { print STDERR localtime() . ": @_\n" }
> >
> > then you better darn well invoke it as:
> >
> > &log("my message");
> >
> > and *not*:
> >
> > log("my message"); # invokes built-in logarithm function
> >
> > And until you know all the perl built-ins, you should use &. And this
> > is what we teach in Learning Perl.
> >
> > Please don't be so quick to dismiss the value of the leading &.
>
> Fortunately the syntax highlighting in my editor of choice allows me to
> distinguish between built-in functions and user defined subroutines.
>
> :-)
Ignoring the smiley for the moment, the problem with syntax highlighters
for Perl is that they aren't reliable. They tend to let you down
exactly in the marginal cases when you could use the help.
What's worse, sometimes a quirk in the syntax highlighter makes people
use non-obvious code because the highlighter can't cope with the obvious
solution.
Currently I'm still using vim's syntax highlighting only out of inertia.
One of these days I'm going to switch it off for good.
Anno
------------------------------
Date: 8 Aug 2007 10:50:10 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Subroutines and '&'
Message-Id: <5htlf2F3m6tjnU2@mid.dfncis.de>
<trudge@gmail.com> wrote in comp.lang.perl.misc:
> On Aug 7, 2:54 pm, mer...@stonehenge.com (Randal L. Schwartz) wrote:
> > >>>>> "~greg" == ~greg <g...@remove-comcast.net> writes:
> >
> > ~greg> It is still required,
> > ~greg> but only when dealing with references (I think)
> >
> > Or when dealing with a subroutine that is the same name as a built-in.
> > See my other post.
> >
>
> In another situation, I find it most useful as well. For example, I
> typically determine what to do in a script by checking an incoming
> parameter of a form:
>
> my $MODE=param('Mode');
> {
> no strict;
> $MODE="GetLogin" unless $MODE; # default sub to execute
> &$MODE; # else execute this sub
> }
>
> This saves a lot of 'if-else' chains. Just my 2 Canadian cents.
I don't see how it saves an "if". The "else..." comment is misleading.
You are making sure that $MODE points to a sub, and *then* (not "else")
you're executing it.
That aside, your code doesn't require an ampersand in the call.
"$MODE->()" would work just as well.
Anno
------------------------------
Date: Wed, 08 Aug 2007 05:55:24 -0700
From: Paul Lalli <mritty@gmail.com>
Subject: Re: Subroutines and '&'
Message-Id: <1186577724.043017.101540@q75g2000hsh.googlegroups.com>
On Aug 8, 6:50 am, anno4...@radom.zrz.tu-berlin.de wrote:
> <tru...@gmail.com> wrote in comp.lang.perl.misc:
> > my $MODE=param('Mode');
> > {
> > no strict;
> > $MODE="GetLogin" unless $MODE; # default sub to execute
> > &$MODE; # else execute this sub
> > }
>
> > This saves a lot of 'if-else' chains. Just my 2 Canadian cents.
>
> I don't see how it saves an "if". The "else..." comment is
> misleading.
> You are making sure that $MODE points to a sub, and *then*
> (not "else") you're executing it.
I'm assuming he meant it prevents the need for something like:
if ($MODE eq 'Foo') {
Foo();
} elsif ($MODE eq 'Bar') {
Bar();
} else {
GetLogin();
}
Really, he's talking about Symrefs here, which is not at all the same
issue as using an & or not on a subroutine.
Paul Lalli
------------------------------
Date: Wed, 8 Aug 2007 15:11:14 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Subroutines and '&'
Message-Id: <pan.2007.08.08.13.11.14@rtij.nl.invlalid>
On Wed, 08 Aug 2007 10:42:00 +0000, anno4000 wrote:
> Ignoring the smiley for the moment, the problem with syntax highlighters
> for Perl is that they aren't reliable. They tend to let you down
> exactly in the marginal cases when you could use the help.
>
> What's worse, sometimes a quirk in the syntax highlighter makes people
> use non-obvious code because the highlighter can't cope with the obvious
> solution.
>
> Currently I'm still using vim's syntax highlighting only out of inertia.
> One of these days I'm going to switch it off for good.
Emacs suffers from much the same problems. F.i. quote like operators are
not properly recognized, making me write:
next if m'^#';
instead of
next if /^#/;
In general I can live with it though.
M4
------------------------------
Date: 8 Aug 2007 13:25:46 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Subroutines and '&'
Message-Id: <5htuiqF3evc1nU1@mid.dfncis.de>
Paul Lalli <mritty@gmail.com> wrote in comp.lang.perl.misc:
> On Aug 8, 6:50 am, anno4...@radom.zrz.tu-berlin.de wrote:
> > <tru...@gmail.com> wrote in comp.lang.perl.misc:
> > > my $MODE=param('Mode');
> > > {
> > > no strict;
> > > $MODE="GetLogin" unless $MODE; # default sub to execute
> > > &$MODE; # else execute this sub
> > > }
> >
> > > This saves a lot of 'if-else' chains. Just my 2 Canadian cents.
> >
> > I don't see how it saves an "if". The "else..." comment is
> > misleading.
> > You are making sure that $MODE points to a sub, and *then*
> > (not "else") you're executing it.
>
> I'm assuming he meant it prevents the need for something like:
> if ($MODE eq 'Foo') {
> Foo();
> } elsif ($MODE eq 'Bar') {
> Bar();
> } else {
> GetLogin();
> }
>
> Really, he's talking about Symrefs here, which is not at all the same
> issue as using an & or not on a subroutine.
Right, that makes sense. It would still be preferable to use a dispatch
table (untested):
my %func = map {
no strict 'refs';
( $_ => \ &{ $_ });
} qw( Foo Bar Baz);
my $mode = param( 'Mode');
( $func{ $mode} || \ &GetLogin)->()
That way the symrefs are restricted to the table setup where they will
only be used with the code-determined qw( Foo Bar Baz). Whatever
value $mode has at run time, only these functions or GetLogin will
be called. The original code could call anything an attacker happens
to know about.
Anno
------------------------------
Date: Wed, 08 Aug 2007 13:55:16 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Subroutines and '&'
Message-Id: <Xns998664F43D7E1asu1cornelledu@127.0.0.1>
trudge@gmail.com wrote in
news:1186563907.206979.98990@d55g2000hsg.googlegroups.com:
> On Aug 7, 2:54 pm, mer...@stonehenge.com (Randal L. Schwartz) wrote:
>> >>>>> "~greg" == ~greg <g...@remove-comcast.net> writes:
>>
>> ~greg> It is still required,
>> ~greg> but only when dealing with references (I think)
>>
>> Or when dealing with a subroutine that is the same name as a
>> built-in. See my other post.
>>
>
> In another situation, I find it most useful as well. For example, I
> typically determine what to do in a script by checking an incoming
> parameter of a form:
>
> my $MODE=param('Mode');
> {
> no strict;
> $MODE="GetLogin" unless $MODE; # default sub to execute
> &$MODE; # else execute this sub
> }
>
> This saves a lot of 'if-else' chains. Just my 2 Canadian cents.
The current exchange rate notwithstanding, not worth much, I am afraid.
The proper way to do this allows you to check if an invalid mode was
provided using a lookup table.
# untested code
my %mode_handlers = (
GetLogin => \&GetLogin,
...
);
my $mode = param('Mode');
my $handler;
if ( exists $mode_handlers{ $mode } ) {
$handler = $mode_handlers{ $mode } ;
}
unless ( defined $handler ) {
$handler = $mode_handlers{ GetLogin };
}
$handler->( ... );
__END__
The exists guard is necessary if you are running under mod_perl or
Fast::CGI or any other environment where you program is expected to
serve multiple requests.
Otherwise, each invalid mode request can increase the memory footprint
of your program.
Sinan
> --
> Amer Neely
Your sig separator is incorrect: It should be dash-dash-space-newline.
Yours is missing a space.
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and
reverse each component for email address)
comp.lang.perl.misc
guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Wed, 8 Aug 2007 12:04:32 -0400
From: "Thrill5" <nospam@somewhere.com>
Subject: Re: Subroutines and '&'
Message-Id: <2PudnSDgpvwMdCTbnZ2dnUVZ_uCinZ2d@comcast.com>
"Martijn Lievaart" <m@rtij.nl.invlalid> wrote in message
news:pan.2007.08.08.13.11.14@rtij.nl.invlalid...
> On Wed, 08 Aug 2007 10:42:00 +0000, anno4000 wrote:
>
>> Ignoring the smiley for the moment, the problem with syntax highlighters
>> for Perl is that they aren't reliable. They tend to let you down
>> exactly in the marginal cases when you could use the help.
>>
>> What's worse, sometimes a quirk in the syntax highlighter makes people
>> use non-obvious code because the highlighter can't cope with the obvious
>> solution.
>>
>> Currently I'm still using vim's syntax highlighting only out of inertia.
>> One of these days I'm going to switch it off for good.
>
> Emacs suffers from much the same problems. F.i. quote like operators are
> not properly recognized, making me write:
>
> next if m'^#';
>
> instead of
>
> next if /^#/;
>
> In general I can live with it though.
>
> M4
I use the now defunct ActiveState plug-in for Visual Studio 2003, and have
never had an issue with it not highlighting code correctly. The only reason
I still use VS2003 is because they don't have a plug-in for VS2005.
------------------------------
Date: Wed, 08 Aug 2007 10:10:53 -0700
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Subroutines and '&'
Message-Id: <86ir7qq7du.fsf@blue.stonehenge.com>
>>>>> "Martijn" == Martijn Lievaart <m@rtij.nl.invlalid> writes:
Martijn> Emacs suffers from much the same problems. F.i. quote like operators are
Martijn> not properly recognized, making me write:
Martijn> next if m'^#';
Martijn> instead of
Martijn> next if /^#/;
Martijn> In general I can live with it though.
That's a flaw with perl-mode. cperl-mode is far better, and actively
maintained. First thing I do with an empty .emacs file is teach it
to replace perl mode with cperl-mode. :)
--
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!
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: 08 Aug 2007 12:35:52 -0500
From: Lawrence Statton <yankeeinexile@gmail.com>
Subject: Re: Subroutines and '&'
Message-Id: <87d4xygc93.fsf@hummer.cluon.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> That's a flaw with perl-mode. cperl-mode is far better, and actively
> maintained. First thing I do with an empty .emacs file is teach it
> to replace perl mode with cperl-mode. :)
>
I agree with the solution to that *particular* problem, but as is oft
said: Nothing but perl can parse Perl with absolute certainty. While
cperl-mode does not get nearly as confused nearly as often as
perl-mode did, I have succeeded in confusing its parser on occasion.
That being said, what superior alternative does the grandparent poster
propose? Merely saying that the syntax-highlighter is imperfect does
not obviate the benefits that even a mediocre highlighter offers.
--
Lawrence Statton - lawrenabae@abaluon.abaom s/aba/c/g
Computer software consists of only two components: ones and
zeros, in roughly equal proportions. All that is required is to
place them into the correct order.
------------------------------
Date: Wed, 08 Aug 2007 17:59:44 -0000
From: trudge@gmail.com
Subject: Re: Subroutines and '&'
Message-Id: <1186595984.894668.78590@q75g2000hsh.googlegroups.com>
On Aug 8, 6:39 am, Paul Lalli <mri...@gmail.com> wrote:
> On Aug 8, 5:05 am, tru...@gmail.com wrote:
>
> > I
> > typically determine what to do in a script by checking an incoming
> > parameter of a form:
>
> > my $MODE=param('Mode');
> > {
> > no strict;
> > $MODE="GetLogin" unless $MODE; # default sub to execute
> > &$MODE; # else execute this sub
>
> > }
>
> > This saves a lot of 'if-else' chains. Just my 2 Canadian cents.
>
> It's also a rather absurdly large security whole. You have no way of
> knowing what that parameter is. You are making the assumption that
> the only way to contact your CGI script is via your form. This is
> incorrect. A user can contact your CGI script without ever going near
> your form.
>
> You are allowing your users to call any subroutine in your program.
>
> Paul Lalli
I see where that would be possible. But would a user not need to know
the name of a subroutine in my script? My goal is to try and combine
as many functions as possible into one script, rather than have 5 or 6
separate scripts to maintain. Which brings up a question: if a user
can call any subroutine in my script, what's to stop them from running
a separate script as well?
If there is no secure way to do this with this particular method I
would like to know so as to fix it.
--
Amer Neely
Web Mechanic - www.webmechanic.softouch.on.ca
------------------------------
Date: Wed, 08 Aug 2007 18:02:00 -0000
From: trudge@gmail.com
Subject: Re: Subroutines and '&'
Message-Id: <1186596120.711685.86800@q75g2000hsh.googlegroups.com>
On Aug 8, 6:50 am, anno4...@radom.zrz.tu-berlin.de wrote:
> <tru...@gmail.com> wrote in comp.lang.perl.misc:
>
>
>
> > On Aug 7, 2:54 pm, mer...@stonehenge.com (Randal L. Schwartz) wrote:
> > > >>>>> "~greg" == ~greg <g...@remove-comcast.net> writes:
>
> > > ~greg> It is still required,
> > > ~greg> but only when dealing with references (I think)
>
> > > Or when dealing with a subroutine that is the same name as a built-in.
> > > See my other post.
>
> > In another situation, I find it most useful as well. For example, I
> > typically determine what to do in a script by checking an incoming
> > parameter of a form:
>
> > my $MODE=param('Mode');
> > {
> > no strict;
> > $MODE="GetLogin" unless $MODE; # default sub to execute
> > &$MODE; # else execute this sub
> > }
>
> > This saves a lot of 'if-else' chains. Just my 2 Canadian cents.
>
> I don't see how it saves an "if". The "else..." comment is misleading.
> You are making sure that $MODE points to a sub, and *then* (not "else")
> you're executing it.
>
> That aside, your code doesn't require an ampersand in the call.
> "$MODE->()" would work just as well.
>
> Anno
You're right - I was a little hasty with my wording. And thanks for
the usage of $MODE sans the leading ampersand.
--
Amer Neely
Web Mechanic - www.webmechanic.softouch.on.ca
------------------------------
Date: Wed, 08 Aug 2007 18:05:49 -0000
From: trudge@gmail.com
Subject: Re: Subroutines and '&'
Message-Id: <1186596349.558474.205410@57g2000hsv.googlegroups.com>
On Aug 8, 9:55 am, "A. Sinan Unur" <1...@llenroc.ude.invalid> wrote:
> tru...@gmail.com wrote innews:1186563907.206979.98990@d55g2000hsg.googlegroups.com:
>
>
>
> > On Aug 7, 2:54 pm, mer...@stonehenge.com (Randal L. Schwartz) wrote:
> >> >>>>> "~greg" == ~greg <g...@remove-comcast.net> writes:
>
> >> ~greg> It is still required,
> >> ~greg> but only when dealing with references (I think)
>
> >> Or when dealing with a subroutine that is the same name as a
> >> built-in. See my other post.
>
> > In another situation, I find it most useful as well. For example, I
> > typically determine what to do in a script by checking an incoming
> > parameter of a form:
>
> > my $MODE=param('Mode');
> > {
> > no strict;
> > $MODE="GetLogin" unless $MODE; # default sub to execute
> > &$MODE; # else execute this sub
> > }
>
> > This saves a lot of 'if-else' chains. Just my 2 Canadian cents.
>
> The current exchange rate notwithstanding, not worth much, I am afraid.
>
> The proper way to do this allows you to check if an invalid mode was
> provided using a lookup table.
>
> # untested code
>
> my %mode_handlers = (
> GetLogin => \&GetLogin,
> ...
> );
>
> my $mode = param('Mode');
>
> my $handler;
>
> if ( exists $mode_handlers{ $mode } ) {
> $handler = $mode_handlers{ $mode } ;
>
> }
>
> unless ( defined $handler ) {
> $handler = $mode_handlers{ GetLogin };
>
> }
>
> $handler->( ... );
>
> __END__
>
> The exists guard is necessary if you are running under mod_perl or
> Fast::CGI or any other environment where you program is expected to
> serve multiple requests.
>
> Otherwise, each invalid mode request can increase the memory footprint
> of your program.
>
> Sinan
Ah, thank you for this suggestion. I will implement this in my
scripts.
--
Amer Neely
Web Mechanic - www.webmechanic.softouch.on.ca
>
> > --
> > Amer Neely
>
> Your sig separator is incorrect: It should be dash-dash-space-newline.
> Yours is missing a space.
>
Fixed now. Thanks.
--
Amer Neely
Web Mechanic - www.webmechanic.softouch.on.ca
------------------------------
Date: Wed, 08 Aug 2007 12:55:33 -0000
From: king <hara.acharya@gmail.com>
Subject: windows perl modules
Message-Id: <1186577733.137459.216970@19g2000hsx.googlegroups.com>
Where can we download windows perl modules.
>From CPAN its very easy to get unix modules. but PPM packages are not
found in CPAN.
Is there any site from where I can download PPM perl modules from.
Thanks inadvance
------------------------------
Date: Wed, 08 Aug 2007 13:42:51 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: windows perl modules
Message-Id: <Xns998662D9B2095asu1cornelledu@127.0.0.1>
king <hara.acharya@gmail.com> wrote in news:1186577733.137459.216970@
19g2000hsx.googlegroups.com:
> Where can we download windows perl modules.
>
>>From CPAN its very easy to get unix modules. but PPM packages are not
> found in CPAN.
>
> Is there any site from where I can download PPM perl modules from.
I am assuming you are using ActiveState's Perl distribution. Did you ever
consider looking in the ActiveState Perl folder in Start -> Programs?
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Wed, 8 Aug 2007 15:51:39 +0200
From: "Petr Vileta" <stoupa@practisoft.cz>
Subject: Re: windows perl modules
Message-Id: <f9ciha$1prm$1@ns.felk.cvut.cz>
king wrote:
> Where can we download windows perl modules.
>
>> From CPAN its very easy to get unix modules. but PPM packages are
>> not found in CPAN.
>
> Is there any site from where I can download PPM perl modules from.
>
I use ActiveState Perl too and I download modules (*.pm) from CPAN,
Activestate and some other repositories. Use PPM.bat (or PPM3.bat or what is
the actual version) and type
help rep
--
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail
from another non-spammer site please.)
------------------------------
Date: Wed, 08 Aug 2007 16:39:57 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: windows perl modules
Message-Id: <qbljb3l6fg8u930gl0frrlsqml159kgu76@4ax.com>
On Wed, 08 Aug 2007 12:55:33 -0000, king <hara.acharya@gmail.com>
wrote:
>Is there any site from where I can download PPM perl modules from.
Well, ppm has AS's repository as the predefined one. Others that you
may add include:
C:\temp>ppm repo
+---------------------------------------------+
¦ id ¦ pkgs ¦ name ¦
+----+-------+--------------------------------¦
¦ 1 ¦ 6808 ¦ ActiveState Package Repository ¦
¦ 2 ¦ 645 ¦ uwinnipeg ¦
¦ 3 ¦ 416 ¦ bribes ¦
¦ 4 ¦ 10432 ¦ trouchelle ¦
¦ 5 ¦ 20 ¦ SoulCage ¦
+---------------------------------------------+
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
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 730
**************************************
