[13185] in Perl-Users-Digest
Perl-Users Digest, Issue: 595 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 19 22:13:06 1999
Date: Thu, 19 Aug 1999 19:10:11 -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, 19 Aug 1999 Volume: 9 Number: 595
Today's topics:
Re: Python for Perl users: random thoughts (Neko)
Re: Python for Perl users: random thoughts (Neko)
Re: Python for Perl users: random thoughts (Abigail)
Re: Python to Perl Conversions (Abigail)
Re: Split comp.lang.perl.misc <cassell@mail.cor.epa.gov>
Re: Split comp.lang.perl.misc <samay1NOtkSPAM@hotmail.com>
taint checking code, not data <squid@panix.com>
Re: Why use Perl when we've got Python?! <mpersico@erols.com>
Re: Why would this autovivify - answers? opinions? <wivey@flash.net>
Re: Why would this autovivify - answers? opinions? <wivey@flash.net>
Digest Administrivia (Last modified: 1 Jul 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 20 Aug 1999 00:10:25 GMT
From: tgy@chocobo.org (Neko)
Subject: Re: Python for Perl users: random thoughts
Message-Id: <7pi6dh$nlv$0@216.39.141.200>
On 19 Aug 1999 08:10:42 -0700, Tom Christiansen <tchrist@mox.perl.com> wrote:
Things I found especially cool were the slices, stacking of relationals (x <
y < z), and doc strings.
I add some notes below.
>SIMILARITY:
> The number zero, the empty string, and the special value None
> are all false. Non-zero numbers and non-empty strings are
> all true. This is all like Perl. But here an empty tuple ()
> is false, as is an empty list [] or an empty dictionary {}.
> In Perl, the last two are true if you write them that way, because
> they're references.
It might be helpful to explicitly state that the string '0' is non-empty and
therefore true in Python whereas it is false in Perl.
>>> a = [ 0, '', None, (), [], {}, '0' ]
>>> for i in a: print not i
...
1
1
1
1
1
1
0
>DISSIMILARITY:
> Python uses [] to create a new empty list, which you
> then reference with [] subscripts.
> Perl uses [] to create a new empty array, which you
> then reference with [] subscripts.
> Python uses {} to create a new empty dictionary, which you
> then reference with [] subscripts.
> Perl uses {} to create a new empty hash, which you
> then reference with {} subscripts.
This looks more like a similarity than dissimilarity.
>COOLNESS:
> Python has a reduce() built-in that works somewhat like map().
Perl doesn't have an equivalent to Python's reduce(). Graham Barr has a
function of same name and functionality in his 'builtin' (now some other
name) module.
>DISSIMILARITY:
> Where Perl says "continue", Python uses "else" (for a loop block).
Perl's "continue" happens each time through a loop unless you call "last".
Python's "else" happens once at the end of a loop unless you call "break".
>GOTCHA: (high)
> Because you can't use readline() to get a number, people seem to enjoy
> calling eval() just to get a string turned into a number:
> import sys
> str = sys.stdin.readline()
> num = eval(x)
> This is scary. Even scarier is the propensity for calling input(),
> which auto-eval()s its input to make sure it's the right "type".
> (Funny that a soi-disant "typeless language" should be so danged
> picky about this.) That means you see people write:
> num = input("Pick a number? ")
> But the person can supply as an answer 0x23 or 2+9 or pow(2,4)
> or os.system("rm -rf *"). I am stunned.
I can only hope Python has taint checking and that if enabled will disable
this.
--
Neko | tgy@chocobo.org | Will hack Perl for a moogle stuffy! =^.^=
------------------------------
Date: 20 Aug 1999 01:11:15 GMT
From: tgy@chocobo.org (Neko)
Subject: Re: Python for Perl users: random thoughts
Message-Id: <7pi9vj$nlv$1@216.39.141.200>
On 20 Aug 1999 00:10:25 GMT, tgy@chocobo.org (Neko) wrote:
>On 19 Aug 1999 08:10:42 -0700, Tom Christiansen <tchrist@mox.perl.com> wrote:
>
>>DISSIMILARITY:
>> Python uses [] to create a new empty list, which you
>> then reference with [] subscripts.
>> Perl uses [] to create a new empty array, which you
>> then reference with [] subscripts.
>> Python uses {} to create a new empty dictionary, which you
>> then reference with [] subscripts.
>> Perl uses {} to create a new empty hash, which you
>> then reference with {} subscripts.
>
>This looks more like a similarity than dissimilarity.
Oops. Thought the subscripts were the same in both. Maybe it should be a
gotcha instead of just dissimilarity.
--
Neko | tgy@chocobo.org | Will hack Perl for a moogle stuffy! =^.^=
------------------------------
Date: 19 Aug 1999 20:23:25 -0500
From: abigail@delanet.com (Abigail)
Subject: Re: Python for Perl users: random thoughts
Message-Id: <slrn7rpbi1.ath.abigail@alexandra.delanet.com>
Tom Christiansen (tchrist@mox.perl.com) wrote on MMCLXXIX September
MCMXCIII in <URL:news:37bc1062@cs.colorado.edu>:
__
__ GOTCHA: (medium)
__ If you have a function that expects two arguments, such as:
__ def fn(x,y):
__ return x + y
__ and you have a tuple of the two elements:
__ t = (1,2)
__ You can't just call that function:
__ print fn(t)
__ Or you get a "TypeError: not enough arguments; expected 2, got 1"
__ error. You have to use this apply() function to get around this
__ issue:
__ print apply(fn,t)
__ 3
That's because tuples don't get flattened. ((1, 2), (3, 4)) is a 2 element
tuple in Python, but a 4 element list in Perl. I can see advantages and
disadvantages. In Perl, if you have:
@foo = (1, 2);
fn (@foo);
fn() might get one or two arguments, depending on the prototype of fn().
Originally Perl would always flatten arrays to lists when calling user
defined functions; but apparently, this was not always considered a good
thing, else the \@ prototype wouldn't have been introduced.
I think that for programmers new to Perl or Python, the flattening of
arrays into lists in Perl is a bigger gotcha than the non-flattening
of tuples in Python is.
__ SIMILARITY:
__ The number zero, the empty string, and the special value None
__ are all false. Non-zero numbers and non-empty strings are
__ all true. This is all like Perl. But here an empty tuple ()
__ is false, as is an empty list [] or an empty dictionary {}.
__ In Perl, the last two are true if you write them that way, because
__ they're references.
0.0 is false is both Perl and Python. (And the fact that "0.0" is
true in Perl is a f*c2!#$ gotcha).
__ DISSIMILARITY:
__ Python uses [] to create a new empty list, which you
__ then reference with [] subscripts.
__ Perl uses [] to create a new empty array, which you
__ then reference with [] subscripts.
__ Python uses {} to create a new empty dictionary, which you
__ then reference with [] subscripts.
__ Perl uses {} to create a new empty hash, which you
__ then reference with {} subscripts.
Perl uses () for creating empty arrays and hashes.
When I thought about Python using [] for both arrays and hashes, I was
trying to find a useful application for that. I thought I had found
one; it would allow someone to easily switch between using arrays and
sparse arrays, as dictionaries/hashes can be used for that. But then,
dictionaries autogrow, while arrays don't, so that would only work if
you can preallocate the size of your datastructure.
__ DISSIMILARITY:
__ In Python, there is no difference between single and double quotes:
__ both interpolate C-style escapes like \t, and neither
__ interpolates variables. In Perl, single quotes do neither escapes
__ nor variables, but double quotes do both.
Python's r"" is more or less equivalent to Perls ''.
__ GOTCHA: (low)
__ Single and double quoted strings can't cross line boundaries.
__ You need triple quotes for that!
I really fail to understand why Python has this. I cannot see the benefit.
__ GOTCHA: (medium)
__ All ranges are up to but *not including* that point. So range(3)
__ is the list [0,1,2]. This is also true in slices, which is the
__ real gotcha part. A slide t[2:5] does not include t[5] in it.
That means that if you want to have a range starting at x, and having
y elements, you can do t [x : x + y]. Which is cool. Imagine having
to do something like t [x : x + y - 1], and having x, y both be 0.
I got bitten by that in Perl using substr() only a few days ago, where
by substr() expression evaluated to substr ($str, 0, -1), which didn't
return the empty string, but the entire string - causing strange and
unexpected behaviour.
Having ranges not include the endpoint is an academic thing to do, and
certainly have its merits; while a bit confusing for the novice, in the
long run, it leads to shorter code, and less off-by-one errors.
__ COOLNESS:
__ Slices can omit either the starting point or the ending point.
__ t[2:5] # elts 2 through 4 (but not 5!)
__ t[:5] # elts up to 4 (but not 5!)
__ t[:-1] # all but the last element (up to but not to -1)
And don't forget: t[:] # A copy of the array/string.
I also like the fact you can use this on strings. str [0 : 5] beats
substr ($str, 0, 5) (!! look, both use 5 here... to get the same substring)
hands down for compactness and clearness.
__ GOTCHA: (high)
__ This is a big surprise: strings are not atomic (although they are
__ immutable). They are instead sequences of characters. This comes
__ up in strange places. For example:
__ >>> for c in ("weird", "bits"):
__ ... print c
__ ...
__ weird
__ bits
__ >>> for c in ("weird"):
__ ... print c
__ ...
__ w
__ e
__ i
__ r
__ d
__ The second case autosplit the characters!
I like this feature. Of course, one has to know that parens here are *not*
part of the for syntax, but part of the subexpression, and that (str) isn't
a 1-element tuple, but a parenthesized expression. Which turns it into:
for c in "weird":
print c
which prints all the characters. DWIM, how Perlesque!
__ GOTCHA: (high)
__ Because everything is a reference, and there's no way to dereference
__ that reference, it turns out that there is no trivial way to copy
__ a list! This fails:
__ x = [1,2]
__ y = x
__ Because you don't get a new list there, just a copy to an
__ old one. Suggested work-arounds include
__ y = x[0:]
__ y = x[:]
__ y = x + []
__ y = x * 1
__ This forces people to think about references, again.
__ So much for lists being first class citizens! Compare
__ this with Perl's
__ @x = (1,2);
__ @y = @x;
__ Or even with references:
__ $x = [1,2];
__ $y = [ @$x ];
__ or
__ @y = @$x;
Don't tell me you find $y = [@$x]; anything cleaner, easier or more
intuitive than y = x [:]!
Perhaps I'm biased, but I know other languages that work that way.
In LPC, you copy an array like this:
copy = orig [..]; /* Only in DGD */
copy = orig + ({ });
I don't find this unintuitative.
__ GOTCHA: (medium)
__ There's no way to set up a permitted exports list. The caller may have
__ anything they ask for.
*cough* And so can a caller in Perl. Don't forget, Perl doesn't do
any exporting. Perl automatically calls a function 'import' for you
if you use "use", but that's about it. The actual "exporting" is done
in user code, as far as Perl is concerned. And a program can redefine
Exporter::import, or Module::import to have the module export anything
found in its symbol table. Or even non-existing things.
__ GOTCHA: (medium)
__ Importing a variable only gives you a local copy. In Perl, it makes
__ two names for the same object.
Well, usually it does. But if a exporter wants to give you a copy, then
the exporter can do so.
__ GOTCHA: (medium)
__ You can't cut and paste these examples because of the issue
__ of white space significance. :-(
I don't understand. Does your X-server eat leading whitespace or so?
Or do you use plain vi, and have ":set autoindent" switched on?
__ DISSIMILARITY:
__ Where Python says "elif", Perl says "elsif".
That's a coolness. "El Sif" is just ugly. ;-)
__ GOTCHA: (medium)
__ The expression 3/4 is 0, which is false. In Perl, 3/4 is 0.75,
__ which is what you'd expect. You need to force the floatness.
__ Sometimes Python is just too tied to C, other time not enough.
__ This is one of the former.
This is very strange. In the recent thread about Python, people blamed
that Perl looks too much like C. At other times, the argument "but C
does this in this way" is used as an argument in a discussion, with
the implicite assumption "if C does it, it's got to be good". However,
having 3/4 return 0.75 is not what a C programmer would expect - just
normal humans would. Based on what is being claimed about Python and
Perl, you'd expect Python to return 0.75 on 3/4, and Perl to return 0.
:-)
__ GOTCHA: (low)
__ Regexes default to emacs style, not egrep style! Gads! This is
__ surprising to anyone except an emacs weenie. Sigh. And just *try*
__ to read the manpage on the differences based on passed in arguments
__ establishing the style. There aren't any manpages! Have a nice day.
I don't understand what you mean by this. Doesn't Python 1.5 have Perl 5.004
regular expressions?
__ GOTCHA: (medium)
__ Anything that python doesn't like, it raises an exception about.
__ There is no fail-soft. Even non-exception issues raise exceptions.
__ It's pervasive. K&P curse languages that force people who want
__ to open() a file to wrap everything in exception code, saying that
__ "failing to open a file is hardly exceptional".
Still, it usually needs to be dealt with. Silently ignoring a failure to
open a file should be exceptional.
__ SIMILARITY:
__ Like Perl, Python requires access to members through a self reference.
__ This gets rid of C++'s icky hidden scope. This is good.
This is one of the reasons I loathe both Perl's and Python's OO model.
All the extra garbage just to get your own variables is pointless.
__ GOTCHA: (low)
__ You have to compiled the definition for a function before you may
__ compile the call it. This is ok
__ def fn():
__ print "hi"
__ fn()
But try this in Perl:
use strict;
sub fn {
my $n = shift;
if ($n > 1) {
return $n * fn --$n;
}
else {
return 1;
}
}
That won't compile. This:
use strict;
sub fn {
my $n = shift;
if ($n > 1) {
$n --;
return ($n + 1) * fn $n;
}
else {
return 1;
}
}
produces a cryptic run-time error about calling a method
While this:
use strict;
sub fn {
my $n = shift;
if ($n > 1) {
$n --;
return ($n + 1) * fn ($n);
}
else {
return 1;
}
}
is all handy-dandy.
Abigail
--
perl -we 'print q{print q{print q{print q{print q{print q{print q{print q{print
qq{Just Another Perl Hacker\n}}}}}}}}}' |\
perl -w | perl -w | perl -w | perl -w | perl -w | perl -w | perl -w | perl -w
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: 19 Aug 1999 20:36:31 -0500
From: abigail@delanet.com (Abigail)
Subject: Re: Python to Perl Conversions
Message-Id: <slrn7rpcap.ath.abigail@alexandra.delanet.com>
Tom Christiansen (tchrist@mox.perl.com) wrote on MMCLXXIX September
MCMXCIII in <URL:news:37bc1142@cs.colorado.edu>:
.. +-----------------------+
.. | Operations on numbers |
.. +-----------------------+
..
.. Python Construct Perl Equivalent
.. ===========================================================================
..
.. x % y same; Perl and Python use the same
.. definition of modulus, even though this
.. differs from that of C with respectd to
.. negative operands.
Well, python uses % for sprintf as well. Which is really odd the first
time you look at it. I do however like the %(key)s feature:
>>> dict = {"aap" : "noot", "mies" : "wim", "zus" : "jet"}
>>> print "One %(aap)s, two %(mies)s", dict
One noot, two wim
>>>
.. x in s No built-ins, must use grep or loop.
.. Lists/arrays: grep { $x == $_ } @s
.. Strings: index($s, $x) != 0
While grep is of course much more general, I do like this. 'x in s' is
more compact, and more clear than 'grep {$x == $_} @s' (which of course
gives warnings if @s contains strings). And considering tons of people
write 'grep {/x/} @s', when they mean 'grep {$_ eq "x"} @s', having "in"
next to grep would IMO, be a worthwhile addition to Perl.
Abigail
--
perl5.004 -wMMath::BigInt -e'$^V=Math::BigInt->new(qq]$^F$^W783$[$%9889$^F47]
.qq]$|88768$^W596577669$%$^W5$^F3364$[$^W$^F$|838747$[8889739$%$|$^F673$%$^W]
.qq]98$^F76777$=56]);$^U=substr($]=>$|=>5)*(q.25..($^W=@^V))=>do{print+chr$^V
%$^U;$^V/=$^U}while$^V!=$^W'
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: Thu, 19 Aug 1999 17:26:36 -0700
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: Split comp.lang.perl.misc
Message-Id: <37BCA0BC.71BBBA8A@mail.cor.epa.gov>
James Liu wrote:
>
> There really should be more perl newsgroups. There are too many posts here.
Yes, but adding more groups doesn't usually help. Look at
comp.unix.wizards, which was created to talk about real tech
stuff, but has been destroyed by newbies who see the word
'wizard' and say to themselves "Hey, I bet the wizards there
could help me figure out which button is the on switch!"
> I guess we could add
>
> comp.lang.perl.reg
> .io
> .win32
> .llama #for newbie posts. this one should
> definately be moderated, with an automated look in FAQ response
Newbies don't know not to post in other places.. or not to
crosspost to irrelevant places. That's why
comp.lang.perl.moderated is the moderated one. Newbies
won't even know what 'llama' means in the newsgroup name.
Or what 'io' stands for. A lot of the traffic on this
newsgroup is from people who aren't even asking Perl
questions at all! How are they going to choose the right
newsgroup from these choices? They'll just crosspost to
all of them at once.
> .database
> .otherlangs #for arguning about which langs are
> better, discussing a2p s2p.
That's usually called comp.lang.whatever.advocacy .
But there is seldom more than a couple threads about other
languages going on here, and the trolls who really want
to create wars don't post to the *.advocacy groups anyway.
They post to the routine groups where they can cause the
most trouble.
> that should really clear up traffic and make finding what people want much
> easier. please suggest others.
This is why the comp.lang.perl.* hierarchy was created in
the first place. If you really don't like all the traffic
on this newsgroup, use a newsreader which permits you to
ignore posts which have keywords in the subject lines, etc.
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: Thu, 19 Aug 1999 17:51:16 +1700
From: Samay <samay1NOtkSPAM@hotmail.com>
Subject: Re: Split comp.lang.perl.misc
Message-Id: <000b8d9b.518eb978@usw-ex0102-010.remarq.com>
comp.lang.perl.starting
or
comp.lang.perl.win32
or
comp.lang.perl.newbee
or
comp.lang.perl.wizard
can certainly help
I cannot determine very will the usefulness of this
groups..compare to c.l.p.m
The post in other groups can simply be ignored by group
people, just like they ignore the CGI questions in Perl
group (most of the time..:-)
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Date: 19 Aug 1999 21:15:18 -0400
From: Yeoh Yiu <squid@panix.com>
Subject: taint checking code, not data
Message-Id: <oxgogg3s15l.fsf@panix7.panix.com>
I see just about every security check advocates taint checking
and laundering data, and cleaning up the $ENV{PATH}.
I don't see anything about a safe way to run random code.
Well, I see references to Penguin, but judging by
http://www.cpan.org/modules/by-module/Penguin/FSG/Penguin-3.00.readme
I would think it's not quite complete, and not actively developed.
What I want to be able to do is eg run Abigail's JAPH .sig not worry.
Maybe run more evil or carelessly copied & pasted code, too.
squid.
------------------------------
Date: Thu, 19 Aug 1999 20:36:45 -0400
From: "Matthew O. Persico" <mpersico@erols.com>
Subject: Re: Why use Perl when we've got Python?!
Message-Id: <37BCA31D.51F16A70@erols.com>
"Mark W. Schumann" wrote:
>
> In article <37B44618.ED01B54@pacbell.net>,
> Miles Egan <milese@pacbell.net> wrote:
> >Of course, now that the STL is a part of standard C++, nobody has much
> >of an excuse to do this in C++.
>
> ["this" being reinventing data structures such as linked lists and
> trees, not "this" as in "like $self"]
>
> Bizarrely, I still see people doing this all the time. I have no
> idea why they don't just use the darned templates and be done with
> it.
Because (IMHO) implementation is only in the latest versions of the
compilers, folks are loathe to upgrade C++ compilers for fear of breaking
existing code with new "bugtures", implementations are uneven at that and
there is no evangalization to use teh templates. We are all spoiled by the
CPAN model.
--
Matthew O. Persico
You'll have to pry my Emacs from my cold dead oversized
control-pressing left pinky finger. -- Randal L. Schwartz
------------------------------
Date: Fri, 20 Aug 1999 01:16:16 GMT
From: "W. Ivey" <wivey@flash.net>
Subject: Re: Why would this autovivify - answers? opinions?
Message-Id: <A%1v3.449$_l2.522@news.flash.net>
Darrin Edwards wrote in message ...
>So if $Label isn't a key in the hash, the request for a hashref
>as the value of $g_DescHash{$Label} causes such autovivification.
Yes, I understand that. I probably should have mentioned that
the label did, in fact, exist. Note in the dump that the blank
entry occurs below the level of the label - not above it as you
would expect if Perl needed to create an entry to resolve a
referencing situation. In fact, this code works perfectly,
returning the expected reference to the entry EXCEPT that the
entry (hash) now contains a blank sub-entry.
>When I try something similar to your first example I get no such warning.
>(Perl doesn't complain that the referred-to hash is uninitialized as long
>as I only play with references to it.)
In my case the hash was initialized, in fact, the the hash and
key value supplied in this instance come from the same source,
so there's no real chance of them not matching.
>perldoc -f exists... if you don't want autovivification, test the
>key for validity first.
I turned up exactly what you did, plus a bit more. I do
appreciate the attempt to help, though.-Wm
------------------------------
Date: Fri, 20 Aug 1999 01:30:24 GMT
From: "W. Ivey" <wivey@flash.net>
Subject: Re: Why would this autovivify - answers? opinions?
Message-Id: <Qc2v3.472$_l2.728@news.flash.net>
Makarand Kulkarni wrote in message <37BC8600.B7499FD4@cisco.com>...
>The empty array you see is because of autovivification.
Of course, but why in this case? The label IS in the
hash, and it DOES return the proper reference to the
correct entry (plus the new blank entry WITHIN that
entry, not at the level at which the label was found).
>But there is no key for $Label
There is (in fact, it would be nearly impossible
for there not to be). Sorry I can't post much more
of the code but, 1. it's huge, 2. I'd be in deep
do-do if I did. What I'm looking for are non-
obvious ideas I can track down. (I promise to
tell the "winner" if an idea works :-)
>and it creates this
>key on the fly and henceforth this value will be a
>hash ref!! You will not be able to do this -
>$g_CurHashRef->[0] etc,
Actually, that should be:
$g_CurHashRef->{sub-label}->[index]
At the top it's a hash of hashes of arrays.And
it works just fine. The only time there's a
problem is when I use foreach to iterate through
all the keys in %{$g_CurHashRef}, then the blank
key shows up. (I could just trap it, but I'd like
to know why it appears.)
>The array message you will get will be something like this --
>Not an ARRAY reference at check.pl line ...
Nope, everything works fine except for the
aforementioned foreach usage. Incidentally,
this works, too, and also inserts the blank
entry:
$g_CurHashRef = $g_DescHash{$Label};
(I've tried a number of variations on the theme.)
-Wm
------------------------------
Date: 1 Jul 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 1 Jul 99)
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.misc (and this Digest), send your
article to perl-users@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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq" from
almanac@ruby.oce.orst.edu. The real FAQ, as it appeared last in the
newsgroup, can be retrieved with the request "send perl-users FAQ" from
almanac@ruby.oce.orst.edu. Due to their sizes, neither the Meta-FAQ nor
the FAQ are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq" from
almanac@ruby.oce.orst.edu.
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 V9 Issue 595
*************************************
