[13381] in Perl-Users-Digest
Perl-Users Digest, Issue: 792 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Sep 14 11:22:02 1999
Date: Tue, 14 Sep 1999 08:10:16 -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 Tue, 14 Sep 1999 Volume: 9 Number: 792
Today's topics:
Re: Searching by date problem. (Benjamin Franz)
Re: Searching by date problem. (Benjamin Franz)
Re: Searching by date problem. (Benjamin Franz)
Re: Searching by date problem. (Larry Rosler)
Re: Searching by date problem. (Benjamin Franz)
Re: Setuid troubles (Kragen Sitaker)
Re: UNCRAP project proposal <uri@sysarch.com>
Re: where is Perl for Win32 build 303? <craig@ariel.hq.group.com>
XML as database ? <luca.orlandi@inferentia.it>
Digest Administrivia (Last modified: 1 Jul 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 14 Sep 1999 13:31:59 GMT
From: snowhare@long-lake.nihongo.org (Benjamin Franz)
Subject: Re: Searching by date problem.
Message-Id: <j7sD3.129$UA3.7475@typhoon01.swbell.net>
In article <slrn7tr7ba.pi.sholden@pgrad.cs.usyd.edu.au>,
Sam Holden <sholden@cs.usyd.edu.au> wrote:
>
>If I say my sister was born in /76 then you should assume I mean 1976. Either
>because she's probably around my age and I'm probably not over 120. Or because
>if she was born in 1876 I would have said /1876 because /76 is just short-hand
>for 1976 (for the moment, in the future it will be shorthand for 2076).
Only if the operators know _how big your window is_. And they probably don't.
You've created a 'magical fixer upper' that will break without warning.
The operator wants to enter historical, current and future events on a timeline.
(Lets say visits of a comet). The last was in 1940. The next was 1990 and
the one after that will be 2040. Today is 1999. Which date should '40'
refer to. Operators will form 'operational guesses' - which quite
likely will not match what your code does. The _closest_ date is 2040.
The _intuitive_ date could be either.
>>
>>In those cases where shorter dates are apparently used, the four digit
>>dates appear much like 'reference frames' in a compressed video - they
>>appear _explicitly_ somewhere else to unambiguously frame the date.
>>And the text itself goes down to the _month_ and day. Thus I have
>>a ledger for _1998_. The entire ledger is _1998_. And the data within
>>says 'January', 'March' etc. With _no_ year immediately adjecent.
>
>That's right in a two digit date is the latest date that it could mean before
>the current date for date inputs for past dates, and the closest date it could
>mean after the current date for inputs for future dates.
Ah. That's a _new_ variation of 'intuitive' that never would have occured
to me. That makes three _different_ variations of what you might do with
a two digit date:
'Intuitive behavior 1') Prepend the current century.
'Intuitive behavior 2') Prepend the century that would make the date _closest_ to now.
'Intuitive behavior 3') Prepend the century that will place the date _before_ now.
Great. Now which one does the _operator_ guess you did? Remember you wrote the
code 15 years ago, left the company 14 years ago, your manager moved on to
greener pastures 5 years ago and the tech writer for the manual joined the
company 2 years ago. And some idiot lost the source code. (Been there - I
wrote a package for a company on contract and two months later they managed
to blow away the source completely. Still wanted the software though.)
>I have never written a four digit year on a cheque I've filled out, or on
>a deposit slip, or on my tax form. There is no need.
Funny. _ALL_ my checks going back the last 20 years have four digits.
Either pre-printed with the century and a blank for the decade and year
until about 5 years ago or completely written out starting a few years ago
(when the check companies quit printing the century on the check to prevent
century errors starting next year).
>>Unambiguous - and with four digit dates.
>
>Two digit years are unambiguous as well.
>
>It lets computers do the work and people be lazy. This is the way it should
>be. 10/10/73 is a valid date. It means 1973 not 2073, or 1873 or 0073. If I
>wanted one of the other ones I would have written them out as above.
>
>Short-cuts are a good thing. They make interfaces easier to use. They make
>poeple more efficient. They save money.
Y2K is costing _tens of billions of dollars_. Funny kind of 'saving time
and money'. I could quite reasonably lay at least a few of those billions
of dollars of _cost_ at the feet of the unknown person who thought 'y-1900'
(two digits for 'convienence' on the short term) in tm_struct. A decision
that is unlikely to have _saved_ anything close to what it _cost_.
People don't quite as neatly compartmentize what they do as you and
Larry suggest. And the person writing a user interface spec may
not even be talking to the final coder. "Ah. A two digit date field.
Ok." There are mis-communications, failure to ask the right questions,
and endless other things that interfere with the creation of useful
software.
The guy asking his question provided no context for his date usage.
_YOU AND I DON'T KNOW_ what date ranges his users will enter.
But you want to suggest it is _ok_ in general to use two digit
dates on user interfaces.
It isn't. "Hey George, what major events happened in 58 AD"?
"Uh....I don't know. The computer won't let me list it. It keeps
trying to start at 1958....."
><snippage>
>
>>These are all side points. The _right thing_ remains four digit years.
>>Two digit years and long term data processing are inherently incompatible.
>>If you want to argue against long term information processing - fine.
>
>Two digit dates for data storage are evil. For data input though they are
>exremely useful. That is how people write dates on a peice of paper, that's
>how they should be able to enter dates into a computer. Of course four digit
>dates are acceptable too, they should not be forced upon the user however.
>
>If I enter 10/10/73 into my application it accepts it just fine, it converts
>it to 10/10/1973 on the screen in front of me. This is how it should be. There
>is no problem caused by this.
>
>Being able to use a two digit year just lets me enter dates faster and takes a
>few more cpu cycles away from seti-at-home or whatever - the way computers
>should work.
And how do you enter 99 AD?
Now consider a form that pre-fills today's century and positions the cursor
for typing the remaining two digits. Ah. I type two digits almost all
the time - _but can type any four digit date_. With no inaccessible
dates. Four digit dates on entry _take no more time on average than
two digit dates_.
The idea that you 'save' _anything_ by 'magically' processing two digit
dates into four digit gates (there-by preventing certain dates from entry)
is fallacious from the word go. It is a _failure_ of the programmer to
think it through that results in that kind of 'solution'. It increases
the number of ways software can break - which is _ALWAYS_ a bad thing.
--
Benjamin Franz
------------------------------
Date: Tue, 14 Sep 1999 13:57:38 GMT
From: snowhare@long-lake.nihongo.org (Benjamin Franz)
Subject: Re: Searching by date problem.
Message-Id: <mvsD3.136$UA3.8932@typhoon01.swbell.net>
In article <MPG.124744dc4ae3d514989f5b@nntp.hpl.hp.com>,
Larry Rosler <lr@hpl.hp.com> wrote:
>[Posted and a courtesy copy mailed.]
>
>I hate to get ad hominem,
Then don't. If you know what ad hominem means, you know why
it carries no weight in a good argument. When you figure out
how to argue facts rather than attack the messenger - come back.
[snip]
>Maybe you should meet Jocelyn Amon. You seem to be functioning on the
>same level of sophistication.
And you should meet the Emperor. I hear he has a very nice set
of New Clothes. Ones that can only be seen by the most sophisticated
of people.
--
Benjamin Franz
------------------------------
Date: Tue, 14 Sep 1999 14:24:42 GMT
From: snowhare@long-lake.nihongo.org (Benjamin Franz)
Subject: Re: Searching by date problem.
Message-Id: <KUsD3.137$UA3.9917@typhoon01.swbell.net>
In article <slrn7trv2q.f00.abigail@alexandra.delanet.com>,
Abigail <abigail@delanet.com> wrote:
>Benjamin Franz (snowhare@long-lake.nihongo.org) wrote on MMCCV September
>MCMXCIII in <URL:news:3CgD3.317$6i5.21591@typhoon01.swbell.net>:
>@@ In article <MPG.1247264746c2eca7989f56@nntp.hpl.hp.com>,
>@@ Larry Rosler <lr@hpl.hp.com> wrote:
>@@ >
>@@ >Although this issue might not have occurred to Benjamin Franz, I think
>@@ >that suggestions to reject two-digit year input for the huge majority of
>@@ >programs are misguided and injure our profession. People have 'always'
>@@ >used two-digit years, and 'always' will continue to do so.
>@@
>@@ Welcome to the 'century bug'. Guess what happens in 2100 - one century
>@@ after everyone 'learns the lesson'. I would argue the opposite.
>
>I think the biggest problem is that people don't listen.
>
>You didn't listen to the previous posters.
Nor they to I. Remarkably symmetric, that.
>@@ These are all side points. The _right thing_ remains four digit years.
>
>What? Doesn't the Y2K issues learn you a single thing? Do you really want
>to repeat history? 4 digit years will create a Y10K bug. That might seem a
>long time away, but people dealing with the storage of higly radioactive
>waste might use dates like Jan 1, 12000. And you wouldn't want to have
>some barrels of nuclear waste delivered at your house 10000 years early,
>now would you?
Fair point, even if phrased humorously. Let me rephrase my position
then - _fully qualified dates_ must be entered. This means that
there can be no 'fixing up'. It is fair to use common era (with signs).
But '20' must be '20 of the common era' - not '1920' or '2020'.
Playing games to 'avoid typing' (which is a fallacy anyway - the
use of 'pre-filled' fields makes the 'two digits are faster to
type than four digits' completely bogus - it takes no more keystrokes
and can take less).
>4 _byte_ years, that's more sensible. And even then you have to watch out.
Actually, that is an example of how the problem got rolling in the first
place: Fixed length fields for open ended data. My recent code all
uses variable length named data fields. It is amazing how many times the
issues of 'but we didn't plan for that' goes away when you use them.
Prediction: The use of 'fixed length' data fields will vanish from
general usage over time. They cause far more trouble than benefit
in most cases.
GPS: 12 bit date field (rolled over two weeks ago to the discomfort
of a few hundred thousand car owners in Japan).
Y2K: Obvious. At least _now_ it's obvious.
2038: Not obvious to most people yet. But it will be.
47 day crash: Windows 98. But then, what windows system stays up that
long in the first place?
Notice a common theme?
>Long term data processing? As in a process that just doesn't want
>to terminate? The point is that you are talking about long term data
>*storage* but you do that as a flame to someone who's talking about
>data processing in context.
What context? Go back to the _original_ message I replied to. Funny.
No context that can be used to indicate two digit dates as sufficient.
That was entirely an invention of the thread that followed.
>If I order something on the web, and type in the expiration date of my
>credit card as Sep 01, most web sites don't think I mean 1 BC, or 1901
>BC. They will assume 2001 BC. Which is perfectly fine. The databases that
>store my credit card information will store the expiration date as 2001.
Except for the card readers that last year retured 'expired' for cards
with expire dates of '01/00'. It happened. A lot of people had to replace
their card readers and the credit card companies had to re-issue cards
with dates of '12/99' for the short term while card readers were being
replaced. Cost a bit of money all around.
Ah, the intersection of ugly facts with another beautiful theory....
>@@ But once you accept that you are going to be storing and using information
>@@ for or covering long periods of time it becomes apparent that 2 digits
>@@ is not _and cannot be made_ adequate. Sliding windows and other sleight
>@@ of hand can't ultimately protect you against the _necessity_ to enter
>@@ four digit dates in the first place. And greatly increase the final
>@@ costs of maintaining systems.
>
>I assume your keyboard has just 2 keys, a 0 and a 1, because that's how
>data should be stored and processed?
Actually, I store data as variable length fields usually. Should
be good until the heat death of the universe.
--
Benjamin Franz
------------------------------
Date: Tue, 14 Sep 1999 07:26:30 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: Searching by date problem.
Message-Id: <MPG.1247fadeffdb40e1989f5f@nntp.hpl.hp.com>
In article <slrn7trv2q.f00.abigail@alexandra.delanet.com> on 14 Sep 1999
02:39:37 -0500, Abigail <abigail@delanet.com> says...
> Benjamin Franz (snowhare@long-lake.nihongo.org) wrote on MMCCV September
> MCMXCIII in <URL:news:3CgD3.317$6i5.21591@typhoon01.swbell.net>:
...
> If I order something on the web, and type in the expiration date of my
> credit card as Sep 01, most web sites don't think I mean 1 BC, or 1901
> BC. They will assume 2001 BC. Which is perfectly fine. The databases that
> store my credit card information will store the expiration date as 2001.
Just think of the interest accrued in the 4000 years since 2001 BC(E).
I think you mean AD, though I might mean CE.
I have observed that many sites that accept credit cards are offering
drop-down lists with the years from 1999 spelled out in all their four-
digit glory. To avoid ambiguity, no doubt.
And our technically enlightened state of California, which for decades
has updated auto license plates with a two-digit sticker, now uses
'2000' squeezed into the same space, so as to be almost illegible. I
wonder if sanity will return by the time '01 rolls around. That's 2001,
Snowhare! We will know in January, '00.
This kind of nonsense is an embarrassment to all of us who know better,
as was the just-survived 9/9/99 pseudo-scare non-event. Some
opportunist fed the media the idea that a string '9999' might have been
used as a sentinel in some programs. No one ever bothered to think that
no-way no-how would a date 9/9/99 ever have been represented as a four-
digit string in any data-processing system, and using '090999' as a
sentinel is too ludicrous even to imagine.
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Tue, 14 Sep 1999 14:42:07 GMT
From: snowhare@long-lake.nihongo.org (Benjamin Franz)
Subject: Re: Searching by date problem.
Message-Id: <39tD3.145$UA3.10382@typhoon01.swbell.net>
In article <MPG.1247fadeffdb40e1989f5f@nntp.hpl.hp.com>,
Larry Rosler <lr@hpl.hp.com> wrote:
>wonder if sanity will return by the time '01 rolls around. That's 2001,
>Snowhare!
:)
>This kind of nonsense is an embarrassment to all of us who know better,
>as was the just-survived 9/9/99 pseudo-scare non-event. Some
>opportunist fed the media the idea that a string '9999' might have been
>used as a sentinel in some programs. No one ever bothered to think that
>no-way no-how would a date 9/9/99 ever have been represented as a four-
>digit string in any data-processing system, and using '090999' as a
>sentinel is too ludicrous even to imagine.
Except, possibly, in a life support monitoring machine in Japan
that malfunctioned for 5 minutes starting at 9/9/99 09:09.
Actual news item. Although possibly simple co-incidence.
--
Benjamin Franz
"People are not only stupider than you imagine, they
are stupider than you _can_ imagine."
------------------------------
Date: Tue, 14 Sep 1999 13:27:49 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: Setuid troubles
Message-Id: <p3sD3.9898$N77.772164@typ11.nn.bcandid.com>
In article <oQqB3.13437$Ze2.404272@nnrp3.clara.net>,
David Anderson <dave.anderson@freeuk.com> wrote:
>I've written a set of modules that I would like to use in a CGI script. I
>would also want to keep the files I write to secure, so I tried running with
>setuid enabled but I get an error "-I not allowed with setuid". But I need
>to include the directory with my modules in it. Can anyone supply any
>tips/work arounds?
use lib
Be extremely careful with setuid. See the setuid man page.
Kragen
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Mon Sep 13 1999
56 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>
------------------------------
Date: 14 Sep 1999 09:33:57 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: UNCRAP project proposal
Message-Id: <x7wvttk46y.fsf@home.sysarch.com>
>>>>> "CN" == Chris Nandor <pudge@pobox.com> writes:
CN> # handling of html syntax. no halting problem solved here. if i
CN> had, i # would have published it in the too small margins of OO
CN> Perl. :-)
CN> Yes, we all know you reviewed the book and were named in it.
that was to plug the book, not me. i just like damian and his book a
lot.
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
"F**king Windows 98", said the general in South Park before shooting Bill.
------------------------------
Date: Tue, 14 Sep 1999 10:42:59 -0400
From: "Craig Barkhouse" <craig@ariel.hq.group.com>
Subject: Re: where is Perl for Win32 build 303?
Message-Id: <rtsnjl591iv59@corp.supernews.com>
> The old builds can be found in
> <URL:ftp://ftp.activestate.com/Perl-Win32/Release/>.
A couple people have pointed this FTP archive out. Thanks, but
unfortunately, the old releases contained therein only go back as far as
build 304. So I'm still looking for build 303. Maybe somebody has it
sitting on their hard drive out there? Even an installed image would
suffice, so long as it hasn't been modified.
The reason I need 303, incidentally, is that I've got a modified version of
303 installed, and I need to determine what the modifications were...
------------------------------
Date: Tue, 14 Sep 1999 14:13:41 GMT
From: lrkwz <luca.orlandi@inferentia.it>
Subject: XML as database ?
Message-Id: <7rll66$j5e$1@nnrp1.deja.com>
I which to write a script which gets input from a form via $cgi->param
(I've plaied with CGI::XMLForm and seems to do his job fine) and write
into an XML file appending news nodes.
XML::DOM seems quite hard to deal with ... any suggestions?
The example:
#!C:/perl/5.005/bin/MSWin32-x86/perl -wT
use strict;
use CGI::XMLForm;
my $cgi = new CGI::XMLForm;
print $cgi->header;
my $fname = $cgi->param('xml_fname');
$fname = 'foo.xml' unless $fname;
if ($cgi->param) {
print $cgi->start_html(-title=>'Aggiornamento file' );
print $cgi->pre($cgi->escapeHTML($cgi->toXML));
print $cgi->end_html;
}
else {
my @queries = ('/BOOKMARKS/SEZIONE/TITOLO*');
# Leggo il file XML per ottenere i nomi delle sezioni
open(FILE, "<$fname") or do {print "Can't open: '$fname'
($!)";die;};
my @sezioni_xml = $cgi->readXML(*FILE, @queries);
my @sezioni;
my $i = 0;
foreach my $sezione ( @sezioni_xml )
{
push @sezioni, $sezione if($i++ % 2);
}
close FILE;
# Outpt della form
print $cgi->start_html(-title=>'Aggiunta link/sezione' );
print "<FORM>\n";
print "<INPUT TYPE='hidden' NAME='/BOOKMARKS/\@xml_fname'
VALUE='CRYPT/crypt.xml'>\n";
print '<TABLE>';
print '<TR><TD>Seleziona la sezione:</TD>';
print '<TD>';
print $cgi->scrolling_list(-name=>'SEZIONE/TITOLO', -size=>'1',
-values=>[@sezioni]);
print '</TD></TR>';
print '<TR><TD>Titolo del
link:</TD>';
print q{<TD><INPUT NAME="LINK/TITOLO"></TD>};
print '<TR><TD>Descrizione:</TD>';
print q{<TD><TEXTAREA ROWS=10 COLS=40
NAME="DESCRIZIONE"></TEXTAREA></TD></TR>};
my $now = localtime(time);
print '<TR><TD>Aggiornato
al:</TD>';
print q{<TD><INPUT readonly=1 NAME="LAST_UPDATED"
VALUE="}.$now.q{"></TD></TR>};
print '<TR><TD>Aggiornato
da:</TD>';
print q{<TD><INPUT readonly=1 NAME="UPDATED_BY" VALUE="}.$ENV
{'REMOTE_USER'}.q{"></TD></TR>};
print "<TR><TD COLSPAN=2><INPUT TYPE='submit'
VALUE='Inserisci'><INPUT TYPE='reset'></TD></TR>\n";
print '</TABLE>';
print "</FORM>\n";
print $cgi->end_html;
}
given foo.xml as:
<?xml version='1.0'?>
<?xml-stylesheet href="../bookmarks.xsl" type="text/xsl"?>
<BOOKMARKS NOME="Crypting e tutto il resto" SIGLA="CRYPT">
<SEZIONE NOME="Security/Crypting">
<TITOLO>2.1 Terza sezione Security/Crypting</TITOLO>
<LINK
HREF="http://intranet.inferentia.it/Consulting/HardDevelopmentArea/Labor
atori/Sicurezza/" EXTERNAL="1">
<TITOLO>Sicurezza e commercio elettronico 4</TITOLO>
<DESCRIZIONE>Documento interno 1</DESCRIZIONE>
<LAST_UPDATED>1/1/80</LAST_UPDATED>
</LINK>
<LINK
HREF="http://intranet.inferentia.it/Consulting/HardDevelopmentArea/Labor
atori/Sicurezza/" EXTERNAL="1">
<TITOLO>Sicurezza e commercio elettronico 5</TITOLO>
<DESCRIZIONE>Documento interno 2</DESCRIZIONE>
</LINK>
<LINK
HREF="http://intranet.inferentia.it/Consulting/HardDevelopmentArea/Labor
atori/Sicurezza/" EXTERNAL="1">
<TITOLO>Sicurezza e commercio elettronico 6</TITOLO>
<DESCRIZIONE>Documento interno 3</DESCRIZIONE>
</LINK>
<LINK
HREF="http://intranet.inferentia.it/Consulting/HardDevelopmentArea/Labor
atori/Sicurezza/" EXTERNAL="1">
<TITOLO>Sicurezza e commercio elettronico 6</TITOLO>
<DESCRIZIONE>Documento interno 3</DESCRIZIONE>
</LINK>
<SEZIONE NOME="Security/Crypting">
<TITOLO>2.1.1 Quarta Security/Crypting</TITOLO>
<LINK
HREF="http://intranet.inferentia.it/Consulting/HardDevelopmentArea/Labor
atori/Sicurezza/" EXTERNAL="1">
<TITOLO>Sicurezza e commercio elettronico
4</TITOLO>
<DESCRIZIONE>Documento interno 1</DESCRIZIONE>
<LAST_UPDATED>1/1/80</LAST_UPDATED>
</LINK>
<LINK
HREF="http://intranet.inferentia.it/Consulting/HardDevelopmentArea/Labor
atori/Sicurezza/" EXTERNAL="1">
<TITOLO>Sicurezza e commercio elettronico
5</TITOLO>
<DESCRIZIONE>Documento interno 2</DESCRIZIONE>
</LINK>
<LINK
HREF="http://intranet.inferentia.it/Consulting/HardDevelopmentArea/Labor
atori/Sicurezza/" EXTERNAL="1">
<TITOLO>Sicurezza e commercio elettronico
6</TITOLO>
<DESCRIZIONE>Documento interno 3</DESCRIZIONE>
</LINK>
<LINK
HREF="http://intranet.inferentia.it/Consulting/HardDevelopmentArea/Labor
atori/Sicurezza/" EXTERNAL="1">
<TITOLO>Sicurezza e commercio elettronico
6</TITOLO>
<DESCRIZIONE>Documento interno 3</DESCRIZIONE>
</LINK>
</SEZIONE>
</SEZIONE>
</BOOKMARKS>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
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 792
*************************************
