[28079] in Perl-Users-Digest
Perl-Users Digest, Issue: 9443 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jul 10 06:05:42 2006
Date: Mon, 10 Jul 2006 03:05:05 -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 Mon, 10 Jul 2006 Volume: 10 Number: 9443
Today's topics:
Re: =?utf-8?Q?Re:_Encoding_of_the_perl_output_?= =?utf- <flavell@physics.gla.ac.uk>
Re: An issue with "Require" <zen13097@zen.co.uk>
Re: converting line input into columns axel@white-eagle.invalid.uk
Re: converting line input into columns <David.Squire@no.spam.from.here.au>
Problem converting euro from windows-1252 to UTF-8 !! <nevosa@gmail.com>
Problem converting euro from windows-1252 to UTF-8 !! <nevosa@gmail.com>
Re: Profanity checking, phonetically. anno4000@radom.zrz.tu-berlin.de
Re: What is a type error? <cdsmith@twu.net>
Re: What is a type error? <marshall.spight@gmail.com>
Re: What is a type error? <jo@durchholz.org>
Re: What is a type error? <cdsmith@twu.net>
Re: What is a type error? <jo@durchholz.org>
Re: What is a type error? <pjb@informatimago.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 10 Jul 2006 09:34:49 +0100
From: "Alan J. Flavell" <flavell@physics.gla.ac.uk>
Subject: Re: =?utf-8?Q?Re:_Encoding_of_the_perl_output_?= =?utf-8?Q?=28=C3=A1_=C3=A9_=C3=AD_=C3=B3=29?=
Message-Id: <Pine.LNX.4.64.0607100921480.31746@ppepc87.ph.gla.ac.uk>
On Mon, 10 Jul 2006, Ben Bullock wrote:
> "Tom" <tomlobato@gmail.com> wrote in message
[...]
> > The below code outputs the rigth string to the console (or files
> > if I open with editors), but if I put it (with open
> > FILE,output.html...) in html file and open with a browser, look
> > the result:
> > a e i o u á é í ó u â î ô û
>
> Switching the encoding of your post to utf8, I get the above
> results. In case you can't see this utf8 post the characters in the
> second line that you complained about are actually all displayed
> correctly when the post encoding is utf8. It looks to me as if Perl
> is working properly,
Fair comment...
> and the problem is not Perl but that the
> browser encoding is not set properly.
Well, the proper place to set the character encoding for a browser is
from the document source - rather than being set in the browser by the
recipient, which is at best a workaround or repair technique.
Just exactly how to set the character encoding from the source has
become a bit complex with the various ifs and buts that have crept in,
but to summarise:
* if the document is arriving via HTTP then the ideal place is
on the HTTP protocol header (Content-type header, charset
attribute[1])
* if the document is browsed locally, or via a protocol which has no
content-type header (such as FTP), then...
+ for HTML: meta http-equiv
+ for XML-based content types: <?xml ... encoding=... ?>
+ for Appendix-C XHTML/1.0: both of the above
+ under some circumstances; a Unicode BOM.
[1] By the way, don't be misled by the name of the MIME "charset"
attribute. It specifies what in current terminology is more
accurately called a "character encoding scheme" (such as utf-8). It
does not specify a "character set" in the sense that term is currently
meant - the "Document Character Set" for HTML/4, as also for all
XML-based markups, is in principle Unicode, even when the encoding
scheme is only us-ascii.
That wasn't meant as a criticism of your posting, just an attempt to
clarify a few points which often seem to get misunderstood.
thanks
--
If the crash doesn't occur immediately, the [development] cycle is broken,
and the result is called a release. -- detha, in the monastery.
------------------------------
Date: 10 Jul 2006 07:24:12 GMT
From: Dave Weaver <zen13097@zen.co.uk>
Subject: Re: An issue with "Require"
Message-Id: <44b2009c$0$4391$da0feed9@news.zen.co.uk>
On 7 Jul 2006 05:18:26 -0700, Bill H <bill@ts1000.us> wrote:
> if ($var == 1)
> {
> require "subprog.pm";
> }
>
I get the impression that you expect this code to be the equivalent
of inserting them contents of subprog.pm inside the body of the if();
it's not. (i.e. require isn't the equivalent of C's #include)
See
perldoc -f require
to find out what require really does.
Perhaps
do "subprog.pm";
is the sort of thing you're thinking of, but it's still a horrible
approach.
What are you trying to achieve by having these conditional requires?
------------------------------
Date: Mon, 10 Jul 2006 07:29:15 GMT
From: axel@white-eagle.invalid.uk
Subject: Re: converting line input into columns
Message-Id: <flnsg.3787$5K2.554@fed1read03>
vanagas99@yahoo.com wrote:
> I was not able
> to get to work any of the previous suggestions. I keep getting
> "Malformed Record" error any way I try it.
> [snip script]
> __DATA__
>
> Physical Security
> Severity : Cat II / Important
> Status : Unknown
> PDI ID : 1836
> [data snipped]
The format of the data given here does not match the format as given
in your original posting. Applying the posted script against data
in a different format means it will not provide the required
results.
Instead it wastes people's time.
As you admit you are not a Perl programmer, I really do think you
should follow the advice of a previous poster and hire someone to
write the required code instead of looking for a freebie.
Axel
------------------------------
Date: Mon, 10 Jul 2006 10:54:33 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: converting line input into columns
Message-Id: <e8t84p$uf$1@gemini.csx.cam.ac.uk>
vanagas99@yahoo.com wrote:
(Note: I *do* address your code problem at the bottom)
> A. Sinan Unur wrote:
>> vanagas99@yahoo.com wrote in
>> news:1152496902.511701.167670@p79g2000cwp.googlegroups.com:
>>
>>> Mr. McClellan, Thanks for the counseling session. Appreciate it.
>>> Great addition to my perl learning experience.....
>> Sarcasm is not going to help you.
>>
[sig snipped]
>
> Sinan,
>
> I understand that. There is no reason for Tad to give a speach, either.
> I hate when people think they own the world. I didn't even know what
> "posting on top" means...
Yet by the time it came to this you had been directed to the posting
guidelines for this group several times, and were clearly not following
them. The explain what top-posting is and the reason it is not liked
here. They also advise not quoting sigs, which you did this time.
> plus, blabing about the sincerity of my "sorry"???
It doesn't sound very sincere when you apologize for whacking someone
whilst continuing to whack them. That's effectively what you're post was
like.
> "Abuse us?? what kind of statement is that?
Perfectly fair. Your failure to give an accurate problem description
wastes the time of everyone who tries to help you. That fits the
definition of abuse (of their time and patience).
As you have no doubt guessed already, this is a tough group. Folks here
are happy to give new posters a couple of chances, politely directing
them to the clpm posting guidelines. If these continue to be ignored,
the new poster soon becomes invisible. It seems that you have already
been kill-filed by two of the most knowledgeable and helpful people here.
The code you quote below does not "work" because it was designed for the
record specification you gave in your first posts, not the data you are
actually feeding it. See comments below.
>
> use strict;
> use warnings;
>
>
> use Data::Dumper;
> use English qw{ -no_match_vars };
>
>
> $INPUT_RECORD_SEPARATOR = '';
>
>
> RECORD:
> while (my $record = <DATA>) {
> my (%record) = $record =~ m{\A \s*
> (Severity)
> :(.+?)
So, this expected a record to start with a 'Severity' field, whereas
your data below shows records starting with a single line that seems to
specify a class of record (e.g. "Physical Security). You're going to
need some thing to capture that, e.g.:
my ($record_class, %record) = $record =~ m{\A \s*
(.+?)
(Severity) \s* :(.+?)
> (Status)
> :(.+?)
> (PDI . ID)
> :(.+?)
> (Finding . Details)
> (.+?)
> (Vulnerability . Discussion)
Your records below seem to have a "Category" field in this position. Is
that supposed to be captured separately? At present it will be swallowed
as part of 'Vulnerability Discussion'.
> (.+?)
> (Manual . Fix . recommendations)
Below you have "Manual Fix Procedures"
> (.+?)
> (References and additional information) (.+?)
You need to put in '.'s (as in the lines above) to match the spaces
between the words in "References and additional information". The 'x'
switch at the end of the match causes whitespace to be ignored (and
permits comments), which is what allows the regex to be laid out nicely
for readability like this.
> \z}xms;
> if (not %record) {
> warn "Malformed record";
> next RECORD;
> }
> else {
> # fix up spacing
> for my $entry ( values %record ) {
> $entry =~ s/^\s+//gm;
> $entry =~ s/\s+$//gm;
> $entry =~ s/\n/ /g;
> }
> print Dumper \%record;
> }
> }
>
> __DATA__
>
> Physical Security
> Severity : Cat II / Important
> Status : Unknown
> PDI ID : 1836
These variable numbers of spaces before the colons are going to cause
the patterns above to fail. There was no space there in your original
post. You will need to allow for this by adding '\s*' in the pattern
before the colons.
> Finding Details
> This vulnerability could not be checked by the program, it must be
> checked manually.
> Vulnerability Discussion
> Category: II Inadequate physical protection can undermine all other
> security precautions utilized to protect the system. This can
> jeopardize the confidentiality, availability, and integrity of the
> system. Physical security of the individual machine is the first line
> protection of any system.
> Manual Fix Procedures
> Ensure the computer equipment is located in a protected controlled
> access area.
> References and additional information
> FSO Checklist: 3.1 CJCSM 6510.01, C-D.3
>
>
> Administrator Documentation
> Severity : Cat II / Important
> Status : Unknown
> PDI ID : 1788
> Finding Details
> This vulnerability could not be checked by the program, it must be
> checked manually.
> Vulnerability Discussion
> Category: II Using a privileged account to perform routine functions
> makes the computer vulnerable to attack by any virus or Trojan Horse
> inadvertently introduced during a session that has been granted full
> privileges. The rule of least privilege should always be enforced.
> Manual Fix Procedures
> Ensure administrative personnel have two accounts assigned, a standard
> user account and an account with membership in the Administrators
> group. Personnel should be instructed to use the less privileged
> account for day-to-day use. Each System Administrator will have a
> unique userid dedicated for administering the system. Each System
> Administrator will have a separate account for normal user tasks. The
> built-in Administrator account will not used to administer the system.
> Administrators will be properly trained. The IAO will maintain a list
> of users belonging to the Administrators group.
> References and additional information
> FSO Checklist: 3.2 DODI 8200.2, E3.4.7 CJCSM 6510.01, A-A.3
>
------------------------------
Date: 10 Jul 2006 01:28:27 -0700
From: "nevosa" <nevosa@gmail.com>
Subject: Problem converting euro from windows-1252 to UTF-8 !!
Message-Id: <1152520107.521691.292120@35g2000cwc.googlegroups.com>
Hi Folks,
I am trying to convert RFC-2047 encode MIME headers to UTF-8. It is
working fine so far using the MIME::WordDecoder and Unicode::MapUTF8
CPAN packages. I have done some unit testing and it seems to work fine
except for when I try to convert windows-1252 encode euro(0x80) symbol
to UTF-8.
Subject: This sub has non-ascii chars.Pound:
?windows-1252?Q?Euro_=80_?=
In this case the conversion simply fails and what i see as output is 2
spaces (0x20 0x20).
Has anyone encountered this before? Any immediate help is appreciated.
Rgds.
Naveen
------------------------------
Date: 10 Jul 2006 01:36:39 -0700
From: "nevosa" <nevosa@gmail.com>
Subject: Problem converting euro from windows-1252 to UTF-8 !!
Message-Id: <1152520599.327770.22920@s13g2000cwa.googlegroups.com>
Hi Folks,
I am trying to convert RFC-2047 encode MIME headers to UTF-8. It is
working fine so far using the MIME::WordDecoder and Unicode::MapUTF8
CPAN packages. I have done some unit testing and it seems to work fine
except for when I try to convert windows-1252 encode euro(0x80) symbol
to UTF-8.
Subject: This sub has non-ascii chars.Pound:
?windows-1252?Q?Euro_=80_?=
In this case the conversion simply fails and what i see as output is 2
spaces (0x20 0x20).
Has anyone encountered this before? Any immediate help is appreciated.
Rgds.
Naveen
------------------------------
Date: 10 Jul 2006 09:18:16 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Profanity checking, phonetically.
Message-Id: <4hekaoF1qv3psU1@news.dfncis.de>
David Squire <David.Squire@no.spam.from.here.au> wrote in comp.lang.perl.misc:
> shrike@cyberspace.org wrote:
>
> [snip]
>
> > Thanks all. I expected this to be oddball enough not to be in the
> > cookbook. The previous poster was correct: it is uid/password
> > combinations that I am checking.
> >
> > Is this sort of thing common enough to bother adding a module to CPAN?
> > I expect to write a module specifically for this. I would call it
> > Text::Soundex::Profanity
> >
> > -Opinions?
>
> Hmmm. Seems like a lot of work to solve a very rare problem. I generate
> random passwords using this:
>
> sub makePassword {
>
> my $PasswordLength = 10;
> $PasswordLength = shift if @_;
>
> my @Chars = split //,
> 'abcdefghjkmnpqrstuvwxyzABCDEFGHJKMNPQRSTUVWXYZ23456789'; # note
> excision of ambiguous characters
> my $Password = '';
> for (1..$PasswordLength) {
> $Password .= $Chars[rand @Chars];
> }
> return $Password;
> }
That's improvable. The generation of the character array can be taken
out of the sub so it doesn't happen each time the sub is called. The
remainder can be compacted:
{
# note excision of ambiguous characters
my @Chars = split //,
'abcdefghjkmnpqrstuvwxyzABCDEFGHJKMNPQRSTUVWXYZ23456789';
sub makePassword {
return join '', @Chars[ map rand @Chars, 1 .. shift || 10];
}
}
> .. which I picked up somewhere (here?) a few years ago and adapted. I
> have yet to see one that looked pronounceable, let alone profane.
Like with all safety measures, the impact of a breach must be weighed
against the expenditure of implementation. If you are running a porn
site your conclusion may be different than when you represent the
holy see.
Anno
------------------------------
Date: Mon, 10 Jul 2006 01:11:12 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f1bab64c1cb09d498976f@news.altopia.net>
I <cdsmith@twu.net> wrote:
> Incidentally, I'm not saying that such a feature would be a good idea.
> It generally isn't provided in languages specifically because it gets to
> be a big pain to maintain all of the type specifications for this kind
> of stuff.
There are other good reasons, too, as it turns out. I don't want to
overstate the "possible" until it starts to sound like "easy, even if
it's a pain". This kind of stuff is rarely done in mainstream
programming languages because it has serious negative consequences.
For example, I wrote that example using variables of type int. If we
were to suppose that we were actually working with variables of type
Person, then things get a little more complicated. We would need a few
(infinite classes of) derived subtypes of Person that further constrain
the possible values for state. For example, we'd need types like:
Person{age:{18..29}}
But this starts to look bad, because we used to have this nice property
called encapsulation. To work around that, we'd need to make one of a
few choices: (a) give up encapsulation, which isn't too happy; (b) rely
on type inference for this kind of stuff, and consider it okay if the
type inference system breaks encapsulation; or (c) invent some kind of
generic constraint language so that constraints like this could be
expressed without exposing field names. Choice (b) is incomplete, as
there will often be times when I need to ascribe a type to a parameter
or some such thing, and the lack of ability to express the complete type
system will be rather limiting. Choice (c), though, looks a little
daunting.
So I'll stop there. The point is that while it is emphatically true
that this kind of stuff is possible, it is also very hard in Java.
Partly, that's because Java is an imperative language, but it's also
because there are fundamental design trade-offs involved between
verbosity, complexity, expressive power, locality of knowledge, etc.
that are bound to be there in all programming languages, and which make
it harder to take one design principle to its extreme and produce a
usable language as a result. I don't know that it's impossible for this
sort of thing to be done in a usable Java-like language, but in any
case, the way to accomplish it is not obvious.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: 10 Jul 2006 00:21:23 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is a type error?
Message-Id: <1152516083.019202.215160@p79g2000cwp.googlegroups.com>
Chris Smith wrote:
>
> But this starts to look bad, because we used to have this nice property
> called encapsulation. To work around that, we'd need to make one of a
> few choices: (a) give up encapsulation, which isn't too happy; (b) rely
> on type inference for this kind of stuff, and consider it okay if the
> type inference system breaks encapsulation; or (c) invent some kind of
> generic constraint language so that constraints like this could be
> expressed without exposing field names. Choice (b) is incomplete, as
> there will often be times when I need to ascribe a type to a parameter
> or some such thing, and the lack of ability to express the complete type
> system will be rather limiting. Choice (c), though, looks a little
> daunting.
Damn the torpedoes, give me choice c!
I've been saying for a few years now that encapsulation is only
a hack to get around the lack of a decent declarative constraint
language.
Marshall
------------------------------
Date: Mon, 10 Jul 2006 09:36:16 +0200
From: Joachim Durchholz <jo@durchholz.org>
Subject: Re: What is a type error?
Message-Id: <e8t0ai$9ad$1@online.de>
Chris Smith schrieb:
> For example, I wrote that example using variables of type int. If we
> were to suppose that we were actually working with variables of type
> Person, then things get a little more complicated. We would need a few
> (infinite classes of) derived subtypes of Person that further constrain
> the possible values for state. For example, we'd need types like:
>
> Person{age:{18..29}}
>
> But this starts to look bad, because we used to have this nice
> property called encapsulation. To work around that, we'd need to
> make one of a few choices: [...] (c) invent some kind of generic
> constraint language so that constraints like this could be expressed
> without exposing field names. [...] Choice (c), though, looks a
> little daunting.
That's not too difficult.
Start with boolean expressions.
If you need to check everything statically, add enough constraints that
they become decidable.
For the type language, you also need to add primitives for type
checking, and if the language is stateful, you'll also want primitives
for accessing earlier states (most notably at function entry).
> So I'll stop there. The point is that while it is emphatically true
> that this kind of stuff is possible, it is also very hard in Java.
No surprise: It's always very hard to retrofit an inference system to a
language that wasn't designed for it.
This doesn't mean it can't be done. Adding genericity to Java was a
pretty amazing feat.
(But I won't hold my breath for a constraint-style type system in Java
anyway... *gg*)
Regards,
Jo
------------------------------
Date: Mon, 10 Jul 2006 01:59:06 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is a type error?
Message-Id: <MPG.1f1bb6b890c74cd2989770@news.altopia.net>
Marshall <marshall.spight@gmail.com> wrote:
> Chris Smith wrote:
> >
> > But this starts to look bad, because we used to have this nice property
> > called encapsulation. To work around that, we'd need to make one of a
> > few choices: (a) give up encapsulation, which isn't too happy; (b) rely
> > on type inference for this kind of stuff, and consider it okay if the
> > type inference system breaks encapsulation; or (c) invent some kind of
> > generic constraint language so that constraints like this could be
> > expressed without exposing field names. Choice (b) is incomplete, as
> > there will often be times when I need to ascribe a type to a parameter
> > or some such thing, and the lack of ability to express the complete type
> > system will be rather limiting. Choice (c), though, looks a little
> > daunting.
>
> Damn the torpedoes, give me choice c!
You and I both need to figure out when to go to sleep. :) Work's gonna
suck tomorrow.
> I've been saying for a few years now that encapsulation is only
> a hack to get around the lack of a decent declarative constraint
> language.
Choice (c) was meant to preserve encapsulation, actually. I think
there's something fundamentally important about information hiding that
can't be given up. Hypothetically, say I'm writing an accounting
package and I've decided to encapsulate details of the tax code into one
module of the application. Now, it may be that the compiler can perform
sufficient type inference on my program to know that it's impossible for
my taxes to be greater than 75% of my annual income. So if my income is
stored in a variable of type decimal{0..100000}, then the return type of
getTotalTax may be of type decimal{0..75000}. Type inference could do
that.
But the point here is that I don't WANT the compiler to be able to infer
that, because it's a transient consequence of this year's tax code. I
want the compiler to make sure my code works no matter what the tax code
is. The last thing I need to to go fixing a bunch of bugs during the
time between the release of next year's tax code and the released
deadline for my tax software. At the same time, though, maybe I do want
the compiler to infer that tax cannot be negative (or maybe it can; I'm
not an accountant; I know my tax has never been negative), and that it
can't be a complex number (I'm pretty sure about that one). I call that
encapsulation, and I don't think that it's necessary for lack of
anything; but rather because that's how the problem breaks down.
----
Note that even without encapsulation, the kind of typing information
we're looking at can be very non-trivial in an imperative language. For
example, I may need to express a method signature that is kind of like
this:
1. The first parameter is an int, which is either between 4 and 8, or
between 11 and 17.
2. The second parameter is a pointer to an object, whose 'foo' field is
an int between 0 and 5, and whose 'bar' field is a pointer to another
abject with three fields 'a', 'b', and 'c', each of which has the full
range of an unconstrained IEEE double precision floating point number.
3. After the method returns, it will be known that if this object
previously had its 'baz' field in the range m .. n, it is now in the
range (m - 5) .. (n + 1).
4. After the method returns, it will be known that the object reached by
following the 'bar' field of the second parameter will be modified so
that the first two of its floating point numbers are guaranteed to be of
the opposite sign as they were before, and that if they were infinity,
they are now finite.
5. After the method returns, the object referred to by the global
variable 'zab' has 0 as the value of its 'c' field.
Just expressing all of that in a method signature looks interesting
enough. If we start adding abstraction to the type constraints on
objects to support encapsulation (as I think you'd have to do), then
things get even more interesting.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: Mon, 10 Jul 2006 10:31:13 +0200
From: Joachim Durchholz <jo@durchholz.org>
Subject: Re: What is a type error?
Message-Id: <e8t3hi$eh2$1@online.de>
Chris Smith schrieb:
> I think
> there's something fundamentally important about information hiding that
> can't be given up.
Indeed.
Without information hiding, with N entities, you have O(N^2) possible
interactions between them. This quickly outgrows the human capacity for
managing the interactions.
With information hiding, you can set up a layered approach, and the
interactions are usually down to something between O(log N) and O(N log
N). Now that's far more manageable.
Regards,
Jo
------------------------------
Date: Mon, 10 Jul 2006 10:45:00 +0200
From: Pascal Bourguignon <pjb@informatimago.com>
Subject: Re: What is a type error?
Message-Id: <87ejwt4zn7.fsf@thalassa.informatimago.com>
Chris Smith <cdsmith@twu.net> writes:
> But the point here is that I don't WANT the compiler to be able to infer
> that, because it's a transient consequence of this year's tax code. I
> want the compiler to make sure my code works no matter what the tax code
> is. The last thing I need to to go fixing a bunch of bugs during the
> time between the release of next year's tax code and the released
> deadline for my tax software. At the same time, though, maybe I do want
> the compiler to infer that tax cannot be negative (or maybe it can; I'm
> not an accountant; I know my tax has never been negative),
Yes, it can. For example in Spain. Theorically, in France IVA can
also come out negative, and you have the right to ask for
reimbursement, but I've never seen a check from French Tax
Administration...
> and that it
> can't be a complex number (I'm pretty sure about that one).
I wouldn't bet on it.
For example, French taxes consider "advantages in nature", so your
income has at least two dimensions, Euros and and "advantages in
nature". Thanksfully, these advantages are converted into Euros, but
you could consider it a product by (complex 0 (- some-factor))...
> I call that
> encapsulation, and I don't think that it's necessary for lack of
> anything; but rather because that's how the problem breaks down.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
------------------------------
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 V10 Issue 9443
***************************************
