[8263] in Perl-Users-Digest
Perl-Users Digest, Issue: 1881 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Feb 12 19:07:24 1998
Date: Thu, 12 Feb 98 16:01:32 -0800
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, 12 Feb 1998 Volume: 8 Number: 1881
Today's topics:
PLEASE HELP!!! (A M Borregana)
Re: POST without a form? (Martien Verbruggen)
Re: Rounding Off Decimal Numbers (susan cassidy)
Re: So what about last summer's RFD? Let's go moderate (I R A Aggie)
Re: time for comp.lang.perl.more-needed ? (Re: repetiti (Nathan V. Patwardhan)
Use versus Require -- One More Time (Eric Weiss)
Re: Using flock? <joe@ispsoft.de>
Re: Why is Tom Christiansen so rude? (Clay Irving)
Re: Why is Tom Christiansen so rude? <gbarr@ti.com>
Re: Why is Tom Christiansen so rude? (Malcolm Hoar)
Win32 Perl, spawn, simulating load <snark@mail.intel.com>
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 12 Feb 1998 21:05:22 GMT
From: A.Migueis@shef.ac.uk (A M Borregana)
Subject: PLEASE HELP!!!
Message-Id: <6bvo6i$546$1@bignews.shef.ac.uk>
I have installed the server winhttpd1.4 in my PC Penthium, and added the
bigperl version4.
I installed everything well but when the server is running and I call the
script it returns me this message:
500 Server Error
The server encountered an internal error or misconfiguration and was unable to
complete your request.
Message: could not read from script
Please contact the server administrator, a.migueis@sheffield.ac.uk and inform
them of the time the error occured, and anything you might have done that may
have caused the error.
If i run it from the command line it the script run...
What is happening??
a.migueis@sheffield.ac.uk
Antonio
------------------------------
Date: 12 Feb 1998 21:42:15 GMT
From: mgjv@comdyn.com.au (Martien Verbruggen)
Subject: Re: POST without a form?
Message-Id: <6bvqbn$a9s$1@comdyn.comdyn.com.au>
[comp.lang.perl is long dead, please notify your news administrator]
In article <34e32a4a.2546145@news.algonet.se>,
odie@algonet.se.REMOVE (Odie Deth) writes:
> I tried fooling around with the "exec" command, but it did absolutely
> _nothing_. I have no idea what I did wrong, but perhaps you can make
> it work. A very clumsy, but working, solution is of course to write
> the parameters to a file, and then call the second script via Meta
> Refresh, and have it read the file.
If you use CGI.pm, it has the tools to do all this.
Martien
--
Martien Verbruggen |
Webmaster www.tradingpost.com.au | Inside every anarchy lurks an old boy
Commercial Dynamics Pty. Ltd. | network - Mitchell Kapor
NSW, Australia |
------------------------------
Date: 12 Feb 1998 12:38:17 -0800
From: susanc@news.SanDiegoCA.ncr.COM (susan cassidy)
Subject: Re: Rounding Off Decimal Numbers
Message-Id: <6bvmjp$6sj@ssd3450.SanDiegoCA.NCR.COM>
In article <34E0762F.20A4@solarcomm.com>,
Chris Wicklas <chrisw@solarcomm.com> wrote:
>Hi all-
>
>I was wondering if someone could give me a hand. I've been trying to get
>a decimal number such as 57.788 to come out as 57.79. I'm having a hard
>time getting this to work. It's for a shopping cart that I'm working on
>and I can't get the final price to come out rounded off after the tax,
>which ususally ends up being some mega-digited number, is added in.
>
>I've tried using the Floating-Point Math Package, but with no luck. I'm
>just learning Perl now and got stuck on this point. Any help that anyone
>could offer would be greatly appreciated.
>
>Thanks in advance-
>Chris
>--
>
>
>Chris Wicklas
Just add half of the size of the rightmost decimal position
in the number you have, then truncate using sprintf or printf,
depending on what you need to do. E.g. to round a number like
57.788 to 57.79, add .0005. To round 57.78 to 57.8 add .005
before truncating. The sprintf or printf will not round, only
truncate to a specified size.
#!/usr/bin/perl
@nums=(57.788, 57.711, 54.555);
foreach $num (@nums) {
$result=sprintf("%3.2f\n",($num + .0005));
print "started with $num, result is $result\n";
}
Hope this helps.
--
Susan Cassidy
Remove xxx in replyto address when replying.
------------------------------
Date: Thu, 12 Feb 1998 17:09:47 -0500
From: fl_aggie@thepentagon.com (I R A Aggie)
Subject: Re: So what about last summer's RFD? Let's go moderated.
Message-Id: <fl_aggie-1202981709470001@aggie.coaps.fsu.edu>
In article <linberg-1202981313190001@projdirc.literacy.upenn.edu>,
linberg@literacy.upenn.edu (Steve Linberg) wrote:
+ Randall
Randal. One L. I've made the same mistake... :)
+ I don't have the skills to be a moderator, but I'd be willing to help out
+ however I can. I don't want to see this resource die due to stupid (and
+ preventable) lowest-common-denominator problems.
Ummm...create "comp.lang.perl.wizards", make it moderated and all posts,
including xposts, go into /dev/null. Most FAQers won't have the Usenet
background to understand that such groups are either a) a wasteland
populated (briefly) by persons like themselves, or b) point to /dev/null.
It may just catch enough FAQ questions to keep the noise down a tad. AFAIK,
it would be fairly easy to do: alt.dev.null does something similar. It
would likely be less work to get this newgroup made than to make clpm a
moderated newsgroup.
James
--
Consulting Minister for Consultants, DNRC
The Bill of Rights is paid in Responsibilities - Jean McGuire
To cure your perl CGI problems, please look at:
<url:http://www.perl.com/CPAN-local/doc/FAQs/cgi/idiots-guide.html>
------------------------------
Date: 12 Feb 1998 21:55:09 GMT
From: nvp@shore.net (Nathan V. Patwardhan)
Subject: Re: time for comp.lang.perl.more-needed ? (Re: repetitive FAQ posts)
Message-Id: <6bvr3t$741@fridge.shore.net>
Remove xx to reply (xxTony.Curtis@vcpc.univie.ac.at) wrote:
: Maybe the clp hierarchy should be extended?
: clp.www or clp.cgi
I'll agree with you when I stop seeing CGI postings in
comp.lang.perl.tk. It's not the name of the newsgroup that dictates
how people will post; it's the number of people who don't know WTF is
going on and hope to get an answer at any expense.
Although the 'misc', in clpm encourages general postings, it's because
people don't open their eyes.
--
Nathan V. Patwardhan
------------------------------
Date: Thu, 12 Feb 1998 17:14:02 -0500
From: eweiss@winchendon.com (Eric Weiss)
Subject: Use versus Require -- One More Time
Message-Id: <MPG.f4d3def314dca489896aa@news.dgsys.com>
I was trying to explain use versus require to a friend and discovered
what appears to be strange behavior compared to the camel book and the
perlfunc manpage...at least for Win32. Moreover the behavior has
changed between build 5.001 (build 107) and Activeware
5.003_07 (Build 315).
Anyway my example was to create a module with the usual Exporter stuff
and three functions and three variables. One of each was put into
@EXPORT, one of each into @EXPORT_OK and the remaining pair left alone.
Call this file pack.pm
Now in a Perl script try calling with
use;
then with
use (list);
then with
require;
For 5.003, the variable that is never exported or export_ok'd is always
available as pack::var, but the subroutine that is never exported is
never reachable. Shouldn't it be? With require, EXPORT'd
subroutines need to be prefixed with pack:: which does not seem to be
the expected behavior. EXPORT_OK's also need pack::
With use (list) EXPORT'd subroutines that are not in the list also need
pack:: I thought everything EXPORT'd was available whether listed or
not and that the list only affected EXPORT_OK.
For 5.001, EXPORT_OK subroutines had to be modified with the package
name. Also with require, EXPORT_OK subroutines could not be reached
even with package names. EXPORT subroutines had to be references
with &pack:: Just pack:: would not work.
So is this what is supposed to be happening? It doesn't seem to
be consistent with the documentation, but is it consistent with other
platforms?
TIA
Eric
------------------------------
Date: Thu, 12 Feb 1998 23:41:21 +0100
From: Jochen Wiedmann <joe@ispsoft.de>
To: Tom Phoenix <rootbeer@teleport.com>
Subject: Re: Using flock?
Message-Id: <34E37A91.8745B1F9@ispsoft.de>
Tom Phoenix wrote:
> Don't release the lock before closing the file. Instead, don't
> release the lock at all - close the file, and Perl and the system
> will take care of everything.
Question arises: What does "flock FILE,8" do? Or, in other words:
Is this even usable?
Thankful for any hint,
Jochen
--
Jochen Wiedmann joe@ispsoft.de
07123 14887
------------------------------
Date: 12 Feb 1998 17:00:28 -0500
From: clay@panix.com (Clay Irving)
Subject: Re: Why is Tom Christiansen so rude?
Message-Id: <6bvrds$85r@panix.com>
In <6bvifl$506@srvr1.engin.umich.edu> gsar@engin.umich.edu (Gurusamy Sarathy) writes:
>>He's not. He was implemented by Ken Thompson.
>Ahh, therein lies the rub. The problem may be that he's still a
>command-line tool. People who get to know the interface _always_
>find him indispensable.
>At the time of his writing, Ken designed him so that he needed
>no maintainence. You see, he rewrites himself every few
>months. Originally, he preferred to use C, but for the last decade
>or so, he has chosen to rewrite himself in the most current Perl.
>The problem with that approach is that Perl itself did not work
>properly on Windows until recently. So the current Tom version
>hasn't had a chance to regression-test himself there. This
>usually meant that he did not even produce friendly-looking error
>messages when run on Windows. Curiously, the most recent version
>even goes ahead and crashes Windows, perhaps because he knows it
>is pointless running there if he cannot do anything useful, which
>seems logical in a cold sorta way. But it is destructive, and
>has a self-limiting effect on the widespread use of Tom.
>I think the time has come for The Perl Institute to sponsor a project
>to manually restart the rewrite cycle, so Tom can port himself into
>portable perl. Nobody has any idea exactly how long this will take.
>I advise people to stay calm, and let Tom evolve into something
>ever more beautiful. Until then, simply ignore the error messages.
The *real* problem is documentation. People don't know how Tom works.
We need a man page (I believe I have omitted some of the options):
NAME
Tom - Perl information server
SYNOPSIS
Tom [ -v ] [ -w ] [ -n ] question
DESCRIPTION
Tom is a user-friendly command line tool that provides a wealth
of information about the Perl programming language.
OPTIONS
-v Verbose mode: Use this option at your own risk. Tom can be
quite prolific if supplied with an acceptable question.
-w Windows mode: Outputs a variety of humorous statements about
GUI, Windows, Bill, anti-programming, demon-spawn, etc. The
question parameter may be ignored.
-n Newbie mode: Outputs information about the documentation you
received with your Perl distribution, FAQs, and common tools
like grep. The question parameter may be ignored.
EXAMPLES
This command:
Tom -w "How do I configure Microsoft IIS to recognize Perl?"
will output text similar to:
Don't be a PoB. Get a real OS. Besides you're question has
nothing to do with Perl.
This command:
Tom "How do I run Perl in a secure mode?"
will output:
I think you should look at the Safe module, at apache's mod_perl,
and the safe cgi environment from
http://www.perl.comCPAN/modules/by-authors/Malcolm_Beattie/safecgiperl-b1.tar.gz
This command:
Tom -v "Is Perl5 Y2K compliant?"
will output:
As the clock draws us relentlessly closer toward 2000, the final year of the second millennium, doom sayers everywhere are
prophesying unprecedented computer failure in every conceivable sector. Known popularly as the Year 2000 Problem, or the
Millennium Bug, this situation is quite easy to explain. Programs that interpret two-digit dates in the form XX as 19XX behave
unpredictably starting in the year 2000 and beyond into the next millennium. If your birthday is ``2/2/05'', are you 101 years old
in 2006, or just one year old?
Cost estimates of fixing this bug range well into the billions of dollars, with the likely threat of at least that much money again
incurred in protracted legal fees due to real and alleged damages. Because of these devastating cost projections, corporations
and government are mounting pressure to secure legally binding statements that all software they use is warranted to be year
2000 compliant.
As you might well guess, this pressure often stems from lawyer-wary insurance companies, who quite reasonably fear
death-by-litigation even more than they might the effects of costs of actual, incurred damages. To defend themselves against
legal perils, organizations all over the world are rushing to secure, in all possible haste, affidavits to the effect that
such-and-such software is year 2000 compliant. They intend to brandish these as some sort of legal shield when the inevitable
chaos strikes, righteously proclaiming themselves free of Y2K taint and redirecting lawsuits toward the signers of the
aforementioned documents.
Remember this: if someone asks you to warrant that your software is free of year 2000 bugs, they're really just looking for an
excuse to sue you if they misuse your software, even if it should happen to be their own fault. Probably they've already forgotten
the terms of their software licence, one which probably read something rather close to the following:
IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THIS SOFTWARE, ITS DOCUMENTATION, OR ANY DERIVATIVES THEREOF,
EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE IS
PROVIDED ON AN ``AS IS'' BASIS, AND THE AUTHORS AND DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE MAINTENANCE,
SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
Did you ever stop to wonder just how long an automobile manufacturer might survive government scrutiny with such an
anti-warranty? Why should software manufacturers be any different? Somehow, though, they do appear to be. Whether such
things survive the courts in the litigational feeding frenzy certain to ensue in a couple of years is something that remains to be
seen. Don't count on anything.
The anxiety about the Y2K situation is reaching an increasingly feverish pitch in most large organizations. Every few days, you
read something else in the popular media forecasting certain havoc. Nearly all these reports are peppered with vague
prevarications or technical confusion. That's not to say that there isn't a real issue here, and that we can go pretending there's
nothing to bother ourselves with. There certainly is. But what that problems stems from, and what can be done about it, is
something usually misunderstood at best. Three commonly repeated lies exacerbate the situation.
Three Popular Y2K Lies
The first lie routinely recounted is that the Y2K problem historically derived from expensive computers of yesteryear whose
memory was so dear that programmers maintained dates in a two-digit format to keep costs under control.
This assertion is demonstrably false. Think about it. A two-digit number requires how much storage? Two bytes, that is, sixteen
bits? No, much less: numeric data are seldom stored in text format, since a more compact representation is readily available. A
two-digit year would be a number ranging between 00 and 99. That can be represented in just 7 bits.
What about using full years, like 1985 or 2010? Those numbers could be represented in just 11 bits. So did those veteran
programmers of old truly gleefully rack up dramatic cost savings at the rate of 4 entire bits per date? Surely this tremendously
precious hardware could have spared 4 bits! And even if not, one could have employed an offset from a reasonable base
instead. If instead of using just the last two digits, years in dates could have been represented not as absolute values but rather
as the number of years since 1900. If so, this too would still fit in those aforementioned 7 bits, at least for a while. Add another
bit, and we're clear until 2156. End of problem. Saving memory was not why it was done.
Although the users of that day may have chosen a non-extensible representation for their years, one that was year % 1900
rather than year - 1900, that doesn't make it a hardware cost issue. It was still a short-sighted, soft design mistake.
The second lie is that this phenomenon is somehow brand new, that in the year 2000, myriad systems will suddenly fail, and
that this kind of thing has never occurred before. Think about the ancient pensioner born in 1895. A program that reads their
birthday as ``95'' will not pay them their months checks, since in 1998, they appear to be only three years old. The year 2000
has not occurred in this equation. The so-called ``year-2000'' problem is in no fashion new, nor is it limited to that year. It will
simply be more evident then.
The third, and by far the gravest lie about Y2K matters, is that your company can, through the acquisition of affidavits of
compliance, protect itself against harm, whether real or litigated. It can't. This faith in legal documents is hollow and in fact
dangerous. The wisest course of action is for you to immediately disabuse yourself of this deceit.
The insidious, underlying root cause of this entire problem is neither the hardware nor the software. No, that would be too easy;
that we know how to fix. Just apply a few hundred billion dollars, and voil`, it's all taken care of.
Unfortunately, that's not it. The real problem is the wetware. That's right: the defect lies not in our computers, nor in their
programming, but rather in ourselves.
Most of the time that people think about dates, they use only the final two digits of the year. They write it on checks. They write
in family Bibles. You hear someone casually say, ``I remember back in '65,'' or ``the Generation of '98 had their collective
consciousness shaken to the roots by their astonishing defeat to the Americans in the Caribbean,'' and you're just supposed to
know what they mean. Just which 65 is that? Assuming a living speaker, it provably has to be 1965. But just which 98 was
that? Why, it was not the current year, but rather way back in 1898, when Spain lost the remainder of their decrepit empire to
those upstart New Worlders and subsequently succumbed to a national soul-searching that permeated throughout their
literature of that age. In both cases, you resolve the ambiguity by inferring the full year from the context, of course. But if you
don't have that context, then you just have to guess. And remember: computers make notoriously bad guessers.
The most horrifying aspect of all this is that even with a perfectly accurate and working computer program, one that is obviously
``Y2K compliant'', you are still in big trouble. Take for example, the famous Unix cal program. Let's check out the current
month.
$ cal 2 98
February 98
Su Mo Tu We Th Fr Sa
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28
Hold on. What was that? Isn't Valentine's Day is supposed to fall on Saturday, not Wednesday, this year? Oops; wrong
millennium! What you really meant to type was:
$ cal 2 1998
February 1998
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
As you see, it doesn't matter whether the programs are compliant, because the humans using them are not! Fixing the
programs is certainly a necessary step, but far, far from sufficient. You can certify every single program in existence, and it still
will not be enough for safety. Until such time as the teeming billions of people in this world -- or even just the many millions
using computers -- are all similarly certified, and warranted not to forget, there can be no safety. And that's not going to happen.
To seek legally binding statements that a particular program cannot be intentionally or unintentionally misused is nothing but a
witch hunt doomed to fail in its ultimate goal of protecting you and yours. You cannot help that there will always be
cluefully-challenged users and programmers out there, or even persons of clue who occasionally have a memory lapse. You
cannot find them, you cannot blame the tool or language, and you cannot protect yourself from them. Every time a human being
thinks about a year in terms of just two digits, the problem reasserts itself. And no one has yet figured out how to fix the
wetware.
Perl
Now, what about Perl? Is Perl ``Year 2000 Compliant''? The answer is that Perl is every bit as Y2K compliant as is your pencil;
no more, and no less. Does that comfort you? It shouldn't. Just as you can commit Y2K transgressions with your pencil, so too
you can do so with Perl -- or with any other tool, for that matter. You don't really even have to go very far out of your way to do
so; witness the demonstration of the perfectly compliant cal program provided above.
The date and time functions supplied with Perl are the gmtime() and localtime() functions, which are derived from their
namesakes from the C programming language. These supply adequate information to determine the year well beyond 2000.
2038 is when trouble strikes, but only for those of us still stuck on 32-bit machines, a somewhat unlikely albeit admittedly not
entirely unthinkable situation.
The year returned by these functions (when used in list context) is, contrary to popular misconception, not by definition a
two-digit year. Rather, it merely happens to be such right now. What it actually is, is the current year minus one thousand nine
hundred. For years between 1900 and 1999 this happens to be a 2-digit decimal number, but that's not going to last long. To
avoid the year 2000 problem, simply do not treat the year as a 2-digit number. Easy to say, and easy to break. Imagine that
you want find out what the year appears to be in five years, so you write code like this.
use Time::localtime;
$then = time() + ( 60 * 60 * 24 * 365 * 5 ); # 5 years from now
$that_year = localtime($then)) -> year;
printf("It shall be 19%d\n", $that_year); # WRONG! 19103
printf("It shall be %d\n", 1900 + $that_year); # right: 2003
As you see, in the wrong hands, even a nominally year 2000 compliant tool such as Perl or cal can be misused by the
underclued or simply the forgetful.
--
Clay Irving <clay@panix.com> I think, therefore I am. I think?
http://www.panix.com/~clay/
------------------------------
Date: Thu, 12 Feb 1998 12:35:33 -0600
From: Graham Barr <gbarr@ti.com>
Subject: Re: Why is Tom Christiansen so rude?
Message-Id: <34E340F4.BBF44738@ti.com>
David Rawle wrote:
>
> Well?
I do not find Tom rude, he is just very blunt and to the point.
And if you answered as many messages a day as he does you would
be the same.
Give the man some credit, he is spreading his help as thinly
as possible in order to help as many as possible.
I have met Tom and find him a very pleasant person to know, and I
admire him for the work he does.
Graham.
--
Originality is the ability to conceal your source.
------------------------------
Date: Thu, 12 Feb 1998 23:25:52 GMT
From: malch@malch.com (Malcolm Hoar)
Subject: Re: Why is Tom Christiansen so rude?
Message-Id: <6c00e2$8nj$2@nntp1.ba.best.com>
In article <6bvrds$85r@panix.com>, clay@panix.com (Clay Irving) wrote:
>Cost estimates of fixing this bug range well into the billions of dollars, with
> the likely threat of at least that much money again
<snip>
Someone that makes such long posts *really* ought to fix
their line wraps ......... ;-)
--
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Malcolm Hoar "The more I practice, the luckier I get". |
| malch@malch.com Gary Player. |
| http://www.malch.com/ Shpx gur PQN. |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Thu, 12 Feb 1998 13:37:11 -0800
From: Mark VanAntwerp <snark@mail.intel.com>
Subject: Win32 Perl, spawn, simulating load
Message-Id: <34E36B87.1BBDA3AF@mail.intel.com>
Hi all --
I'm using Perl for Win32 and am starting to embark on a series
of scripts to generate load on a fileserver. "Load" will simply
be writing and reading of files to the fileserver.
I'm interested in using a single machine to write/read many files
at once, so I'd like to fork off a bunch of children to do the work.
Well, no fork in NT, so I'm left with spawn. I'm new to spawn,
so does anyone have any good examples or advice to ramp this
quickly?
Anyone done anything that would be helpful in the load-generating
arena? (remember, just file reading/writing) (and on NT...)
Responses to both snark@intel.com and the newsgroup are appreciated.
Thanks!
-Mark
--
Mark VanAntwerp
snark@intel.com I do not speak for Intel.
------------------------------
Date: 8 Mar 97 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 8 Mar 97)
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". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". 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". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 1881
**************************************
