[30564] in Perl-Users-Digest
Perl-Users Digest, Issue: 1807 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Aug 20 16:09:48 2008
Date: Wed, 20 Aug 2008 13:09:10 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 20 Aug 2008 Volume: 11 Number: 1807
Today's topics:
Re: CLPM - a help group? <cwilbur@chromatico.net>
Re: CLPM - a help group? <sbour@niaid.hin.gow>
Re: CLPM - a help group? <sbour@niaid.hin.gow>
Re: Help: Characters with colors <smallpond@juno.com>
Re: Help: Characters with colors <brian.helterline@hp.com>
Re: Help: Characters with colors <magloca@mailinater.com>
Re: Help: Characters with colors <magloca@mailinater.com>
Problem With Crypt::CBC <hal@halblog.com>
Re: Problem With Crypt::CBC sln@netherlands.com
Re: Problem With Crypt::CBC <hal@halblog.com>
Re: Repeating the array <tzz@lifelogs.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 20 Aug 2008 12:47:21 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: CLPM - a help group?
Message-Id: <863akzeiqu.fsf@mithril.chromatico.net>
>>>>> "TJMcC" == Tad J McClellan <tadmc@seesig.invalid> writes:
TJMcC> John Bokma <john@castleamber.com> wrote:
>> *ploink*
TJMcC> I did that 5 years ago.
In the case of people who change their From line, how do you handle it?
I must admit that I'm spoiled by Gnus adaptive scoring. The only people
I have to kill manually are the ones who are such trainwrecks that I
keep reading their posts even though I shouldn't. For the average
troll, just killing the threads is sufficient. But that breaks when
they change their From lines.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: Wed, 20 Aug 2008 10:34:39 -0700
From: "Stephan Bour" <sbour@niaid.hin.gow>
Subject: Re: CLPM - a help group?
Message-Id: <PAYqk.18797$mh5.10823@nlpi067.nbdc.sbc.com>
John Bokma wrote:
:: "Stephan Bour" <sbour@niaid.nih.temp.gov> wrote:
:: ^^^^
Yes I temporarily changed it, because no one is obligated to give anyone
else the last word.
:: You couldn't have made my point more clear.
::
::: It's nice to see that you obviously endorse the inventing alternate
::
:: yeah, the inventing alternate, whatever, shit stain. *ploink*
If anyone has created a stain on this group, it's the people who have become
so obsessed with telling people to RTFM, who purposely misquote, and even
down right lie at times. Some of you have become so out of touch with
reality it truly is laughable. Guess what, Usenet was never created solely
for the Academia world, it was created for everyone. Usenet exists as a
decentralized entity, so no single person governs it, and no one person can
lay kingship of a newsgroup as some of you repeatedly pretend to do. But go,
keep living in your fantasy world where you are king and lord and behave in
any anti-social manner you wish.
Tad J McClellan wrote:
:: I did that 5 years ago.
Not possible, since I wasn't here 5 years ago, so take your assumptions,
take your lies, and get real.
Stephan.
------------------------------
Date: Wed, 20 Aug 2008 10:38:33 -0700
From: "Stephan Bour" <sbour@niaid.hin.gow>
Subject: Re: CLPM - a help group?
Message-Id: <tEYqk.18798$mh5.13458@nlpi067.nbdc.sbc.com>
Sherm Pendley wrote:
:: "Stephan Bour" <sbour@niaid.nih.gov> writes:
::
::: Again, you ignored what he has said
::
:: It's called "critical thinking."
No, it's called being purposely ignoring parts of what was said that change
the meaning completely. It's a very deceptive practice, one often imployed
to gain the upper hand in an arguement without actually having a real
arugement. Well done.
Stephan.
------------------------------
Date: Wed, 20 Aug 2008 11:44:35 -0400
From: smallpond <smallpond@juno.com>
Subject: Re: Help: Characters with colors
Message-Id: <c955d$48ac3bed$30588@news.teranews.com>
Amy Lee wrote:
> On Wed, 20 Aug 2008 14:40:47 +0000, Jürgen Exner wrote:
>
>> Amy Lee <openlinuxsource@gmail.com> wrote:
>>> How to modify the color of characters when I display them?
>> That depends _VERY_ on much how and where you display them. "perldoc -q
>> color"
>> How do I print something out in color?
>> may help get you started.
>>
>> jue
> Thank you very much. Anyway, when I want to search some keywords, could I
> use "perldoc -q <keyword>"?
>
That's actually answered by:
perldoc perldoc
--S
** Posted from http://www.teranews.com **
------------------------------
Date: Wed, 20 Aug 2008 09:47:46 -0700
From: Brian Helterlilne <brian.helterline@hp.com>
Subject: Re: Help: Characters with colors
Message-Id: <g8hhrk$gnh$1@usenet01.boi.hp.com>
Amy Lee wrote:
> On Wed, 20 Aug 2008 14:40:19 +0000, Lars Eighner wrote:
>
>> In our last episode, <pan.2008.08.20.14.25.29.189243@gmail.com>, the lovely
>> and talented Amy Lee broadcast on comp.lang.perl.misc:
>>
>>> open KER_VER, "<", "/root/version";
>>> while (<KER_VER>)
>>> {
>>> unless (/\s+2.4.\d+/)
>>> {
>>> die BOLD RED "Your kernel version is not 2.4.x.\n"
>>> }
>>> }
>>
>>> I hope clean this internal output by perl, how could I do that?
>>> Thank you very much~
>> You can write ansi codes directly, but in spite of ansi being
>> more or less a standard, there are serious portability problems.
>> Some terminals are not ansi capable and others may be quirky.
> Thank you, but it seems that it's for 'print', not for 'die'. How do I
> handle with color when I use 'die'?
Read the documentation for the other interface - colored(). It returns a
string with the codes embedded.
die colored( "Your kernel version is not 2.4.x.\n", 'bold red' );
--
-brian
------------------------------
Date: Wed, 20 Aug 2008 19:01:00 +0200
From: magloca <magloca@mailinater.com>
Subject: Re: Help: Characters with colors
Message-Id: <48ac4dcc$0$4241$6e1ede2f@read.cnntp.org>
Amy Lee @ Wednesday 20 August 2008 16:53:
> On Wed, 20 Aug 2008 14:40:19 +0000, Lars Eighner wrote:
>
>> In our last episode, <pan.2008.08.20.14.25.29.189243@gmail.com>, the
>> lovely and talented Amy Lee broadcast on comp.lang.perl.misc:
>>
>>> open KER_VER, "<", "/root/version";
>>> while (<KER_VER>)
>>> {
>>> unless (/\s+2.4.\d+/)
>>> {
>>> die BOLD RED "Your kernel version is not 2.4.x.\n"
>>> }
>>> }
>>
>>
>>> I hope clean this internal output by perl, how could I do that?
>>
>>> Thank you very much~
>>
>> You can write ansi codes directly, but in spite of ansi being
>> more or less a standard, there are serious portability problems.
>> Some terminals are not ansi capable and others may be quirky.
> Thank you, but it seems that it's for 'print', not for 'die'. How do I
> handle with color when I use 'die'?
How about (untested):
import Term::ANSIColor;
# ...interesting stuff happens...
die colored ("Your kernel version is not 2.4.x.", "bold red");
m.
------------------------------
Date: Wed, 20 Aug 2008 19:05:36 +0200
From: magloca <magloca@mailinater.com>
Subject: Re: Help: Characters with colors
Message-Id: <48ac4ee0$0$4241$6e1ede2f@read.cnntp.org>
magloca @ Wednesday 20 August 2008 19:01:
> How about (untested):
>
> import Term::ANSIColor;
> # ...interesting stuff happens...
> die colored ("Your kernel version is not 2.4.x.", "bold red");
Hmm... That should be 'use Term::ANSIColor', of course... Contamination
from other languages. Sorry.
m.
------------------------------
Date: Wed, 20 Aug 2008 16:27:09 GMT
From: Hal Vaughan <hal@halblog.com>
Subject: Problem With Crypt::CBC
Message-Id: <xBXqk.360$lf2.277@trnddc07>
I've been using Crypt::CBC in Perl on Linux, Debian Sarge, for about 4 years
or so and I haven't had a problem. My Perl script has to output data that
is later read in by a Java program. The Java program is on a number of
different computers for friends and other people I work with and updating
the Java program would be a nightmare, so I want to be sure any changes I
make to fix this problem do not require me to change things on the Java end
of the situation.
I just recently had to upgrade my system from Debian Sarge to Etch, or, more
accurately, the system drive crashed and I decided I might as well put Etch
on the new one (since Lenny is expected out soon anyway). Etch uses
Crypt::CBC version 2.22. I don't remember what version was being used
previously.
Also, I am NOT a crypto person. When I set this up, I had to go over a lot
of examples and do a fair amount of testing and basically used what I could
easily get to work with the Perl and Java programs sending data back and
forth to each other. I've had a particularly hard time grasping
cryptography issues for some reason.
Here's the problem: My code that used to work doesn't and here's the
offending line:
$cipher = Crypt::CBC->new( { 'key' => $pw, 'iv' => $vector,
'prepend_iv' => 0, 'cipher' => 'Blowfish',
'regenerate_key' => 0 , 'padding' => 'standard'} );
Now when the interpreter gets here, I get this error message:
If specified by -literal_key, then the key length must be equal to the
chosen cipher's key length of 56 bytes at threshPerl/Encryption.pm line 82
I wasn't using literal_key and I put in:
'literal_key' => 0
Then ran it and finally figured out from the error that using
the 'regenerate_key' as false forced literal_key to be true, since the two
apparently have to match.
The passwords I am currently using are 8 bytes, or 64 characters and
changing them would be as much of a pain right now as updating the Java
program. Here's the code I use on the Java end for decrypting this same
data:
byte[] bDecrypted;
String cryptoKey, cryptoVector;
...
try {
SecretKeySpec oKey = new
SecretKeySpec(cryptoKey.getBytes("UTF8"), "Blowfish");
IvParameterSpec oIV = new
IvParameterSpec(cryptoVector.getBytes("UTF8"));
Cipher oCipher = Cipher.getInstance("Blowfish/CBC/PKCS5Padding");
oCipher.init(Cipher.DECRYPT_MODE, oKey, oIV );
bDecrypted = oCipher.doFinal(bCrypto);
} catch (Exception e) {
// do error stuff, details don't matter here
}
What I'd like to be able to do is fix this one line of Perl code so I can
continue using the passwords and vectors I'm using (both 8 bytes, or 64
bits) and not have to change the Java code to get it to receive the data.
Also, I'm figuring I'm going to have the same problem with incoming data as
well, but I would expect the solution in that case to be almost the same.
Is there a way I can change this one line of code without having to change
anything on the Java end and still be able to use my current passwords?:
$cipher = Crypt::CBC->new( { 'key' => $pw, 'iv' => $vector,
'prepend_iv' => 0, 'cipher' => 'Blowfish',
'regenerate_key' => 0 , 'padding' => 'standard'} );
I know I should replace regenerate_key with literal_key, but is the actual
difference between using the literal key and and a hash? I take it if I
use the hash, then the Java program on the other end will not be able to
decode with the same password -- that it would need the hashed form of it.
Is that right?
Thanks for any help and insight on this!
Hal
------------------------------
Date: Wed, 20 Aug 2008 17:49:12 GMT
From: sln@netherlands.com
Subject: Re: Problem With Crypt::CBC
Message-Id: <47moa45hlijl9pasklcvd20ug6ojsd901l@4ax.com>
On Wed, 20 Aug 2008 16:27:09 GMT, Hal Vaughan <hal@halblog.com> wrote:
>I've been using Crypt::CBC in Perl on Linux, Debian Sarge, for about 4 years
>or so and I haven't had a problem. My Perl script has to output data that
>is later read in by a Java program. The Java program is on a number of
>different computers for friends and other people I work with and updating
>the Java program would be a nightmare, so I want to be sure any changes I
>make to fix this problem do not require me to change things on the Java end
>of the situation.
>
>I just recently had to upgrade my system from Debian Sarge to Etch, or, more
>accurately, the system drive crashed and I decided I might as well put Etch
>on the new one (since Lenny is expected out soon anyway). Etch uses
>Crypt::CBC version 2.22. I don't remember what version was being used
>previously.
>
>Also, I am NOT a crypto person. When I set this up, I had to go over a lot
>of examples and do a fair amount of testing and basically used what I could
>easily get to work with the Perl and Java programs sending data back and
>forth to each other. I've had a particularly hard time grasping
>cryptography issues for some reason.
>
>Here's the problem: My code that used to work doesn't and here's the
>offending line:
>
>$cipher = Crypt::CBC->new( { 'key' => $pw, 'iv' => $vector,
> 'prepend_iv' => 0, 'cipher' => 'Blowfish',
> 'regenerate_key' => 0 , 'padding' => 'standard'} );
>
>Now when the interpreter gets here, I get this error message:
>
>If specified by -literal_key, then the key length must be equal to the
>chosen cipher's key length of 56 bytes at threshPerl/Encryption.pm line 82
>
>I wasn't using literal_key and I put in:
>
>'literal_key' => 0
>
>Then ran it and finally figured out from the error that using
>the 'regenerate_key' as false forced literal_key to be true, since the two
>apparently have to match.
>
>The passwords I am currently using are 8 bytes, or 64 characters and
>changing them would be as much of a pain right now as updating the Java
>program. Here's the code I use on the Java end for decrypting this same
>data:
>
>byte[] bDecrypted;
>String cryptoKey, cryptoVector;
>...
>try {
> SecretKeySpec oKey = new
> SecretKeySpec(cryptoKey.getBytes("UTF8"), "Blowfish");
> IvParameterSpec oIV = new
> IvParameterSpec(cryptoVector.getBytes("UTF8"));
> Cipher oCipher = Cipher.getInstance("Blowfish/CBC/PKCS5Padding");
> oCipher.init(Cipher.DECRYPT_MODE, oKey, oIV );
> bDecrypted = oCipher.doFinal(bCrypto);
>} catch (Exception e) {
> // do error stuff, details don't matter here
>}
>
>What I'd like to be able to do is fix this one line of Perl code so I can
>continue using the passwords and vectors I'm using (both 8 bytes, or 64
>bits) and not have to change the Java code to get it to receive the data.
>
>Also, I'm figuring I'm going to have the same problem with incoming data as
>well, but I would expect the solution in that case to be almost the same.
>
>Is there a way I can change this one line of code without having to change
>anything on the Java end and still be able to use my current passwords?:
>
>$cipher = Crypt::CBC->new( { 'key' => $pw, 'iv' => $vector,
> 'prepend_iv' => 0, 'cipher' => 'Blowfish',
> 'regenerate_key' => 0 , 'padding' => 'standard'} );
>
>I know I should replace regenerate_key with literal_key, but is the actual
>difference between using the literal key and and a hash? I take it if I
>use the hash, then the Java program on the other end will not be able to
>decode with the same password -- that it would need the hashed form of it.
>Is that right?
>
>Thanks for any help and insight on this!
>
>
>Hal
I'm not a crypt expert, but try this:
$cipher = Crypt::CBC->new( -key => $pw,
-cipher => 'Blowfish',
-iv => $vector,
-header => 'none',
-literal_key => 1,
-padding => 'standard',
-keysize => 8,
);
#-blocksize => 8,
http://search.cpan.org/~lds/Crypt-CBC-2.29/CBC.pm
The -key argument provides either a passphrase to use
to generate the encryption key, or the literal value of
the block cipher key. If used in passphrase mode
(which is the default), -key can be any number of
characters; the actual key will be derived by passing
the passphrase through a series of MD5 hash operations.
To take full advantage of a given block cipher, the
length of the passphrase should be at least equal to
the cipher's blocksize. To skip this hashing operation
and specify the key directly, pass a true value to the
-literal_key option. In this case, you should choose a
key of length exactly equal to the cipher's key length.
You should also specify the IV yourself and a
-header mode of 'none'.
--------------------------
Making a hash of a key phrase just generates a MD5 hash to be used
as a key, that is the default.
Your not doing that, so basically, the -keysize should be equal
to the length of $pw, 8 bytes.
To switch from literal key, you would have to initialize your Java objects
to make hashes of the key.
sln
------------------------------
Date: Wed, 20 Aug 2008 18:23:35 GMT
From: Hal Vaughan <hal@halblog.com>
Subject: Re: Problem With Crypt::CBC
Message-Id: <HiZqk.352$Ro1.123@trnddc04>
sln@netherlands.com wrote:
> On Wed, 20 Aug 2008 16:27:09 GMT, Hal Vaughan <hal@halblog.com> wrote:
>
>>I've been using Crypt::CBC in Perl on Linux, Debian Sarge, for about 4
>>years
>>or so and I haven't had a problem. My Perl script has to output data that
>>is later read in by a Java program. The Java program is on a number of
>>different computers for friends and other people I work with and updating
>>the Java program would be a nightmare, so I want to be sure any changes I
>>make to fix this problem do not require me to change things on the Java
>>end of the situation.
>>
>>I just recently had to upgrade my system from Debian Sarge to Etch, or,
>>more accurately, the system drive crashed and I decided I might as well
>>put Etch
>>on the new one (since Lenny is expected out soon anyway). Etch uses
>>Crypt::CBC version 2.22. I don't remember what version was being used
>>previously.
>>
>>Also, I am NOT a crypto person. When I set this up, I had to go over a
>>lot of examples and do a fair amount of testing and basically used what I
>>could easily get to work with the Perl and Java programs sending data back
>>and
>>forth to each other. I've had a particularly hard time grasping
>>cryptography issues for some reason.
>>
>>Here's the problem: My code that used to work doesn't and here's the
>>offending line:
>>
>>$cipher = Crypt::CBC->new( { 'key' => $pw, 'iv' => $vector,
>> 'prepend_iv' => 0, 'cipher' => 'Blowfish',
>> 'regenerate_key' => 0 , 'padding' => 'standard'} );
>>
>>Now when the interpreter gets here, I get this error message:
>>
>>If specified by -literal_key, then the key length must be equal to the
>>chosen cipher's key length of 56 bytes at threshPerl/Encryption.pm line 82
>>
>>I wasn't using literal_key and I put in:
>>
>>'literal_key' => 0
>>
>>Then ran it and finally figured out from the error that using
>>the 'regenerate_key' as false forced literal_key to be true, since the two
>>apparently have to match.
>>
>>The passwords I am currently using are 8 bytes, or 64 characters and
>>changing them would be as much of a pain right now as updating the Java
>>program. Here's the code I use on the Java end for decrypting this same
>>data:
>>
>>byte[] bDecrypted;
>>String cryptoKey, cryptoVector;
>>...
>>try {
>> SecretKeySpec oKey = new
>> SecretKeySpec(cryptoKey.getBytes("UTF8"), "Blowfish");
>> IvParameterSpec oIV = new
>> IvParameterSpec(cryptoVector.getBytes("UTF8"));
>> Cipher oCipher = Cipher.getInstance("Blowfish/CBC/PKCS5Padding");
>> oCipher.init(Cipher.DECRYPT_MODE, oKey, oIV );
>> bDecrypted = oCipher.doFinal(bCrypto);
>>} catch (Exception e) {
>> // do error stuff, details don't matter here
>>}
>>
>>What I'd like to be able to do is fix this one line of Perl code so I can
>>continue using the passwords and vectors I'm using (both 8 bytes, or 64
>>bits) and not have to change the Java code to get it to receive the data.
>>
>>Also, I'm figuring I'm going to have the same problem with incoming data
>>as well, but I would expect the solution in that case to be almost the
>>same.
>>
>>Is there a way I can change this one line of code without having to change
>>anything on the Java end and still be able to use my current passwords?:
>>
>>$cipher = Crypt::CBC->new( { 'key' => $pw, 'iv' => $vector,
>> 'prepend_iv' => 0, 'cipher' => 'Blowfish',
>> 'regenerate_key' => 0 , 'padding' => 'standard'} );
>>
>>I know I should replace regenerate_key with literal_key, but is the actual
>>difference between using the literal key and and a hash? I take it if I
>>use the hash, then the Java program on the other end will not be able to
>>decode with the same password -- that it would need the hashed form of it.
>>Is that right?
>>
>>Thanks for any help and insight on this!
>>
>>
>>Hal
>
> I'm not a crypt expert, but try this:
>
> $cipher = Crypt::CBC->new( -key => $pw,
> -cipher => 'Blowfish',
> -iv => $vector,
> -header => 'none',
> -literal_key => 1,
> -padding => 'standard',
> -keysize => 8,
> );
> #-blocksize => 8,
>
> http://search.cpan.org/~lds/Crypt-CBC-2.29/CBC.pm
>
> The -key argument provides either a passphrase to use
> to generate the encryption key, or the literal value of
> the block cipher key. If used in passphrase mode
> (which is the default), -key can be any number of
> characters; the actual key will be derived by passing
> the passphrase through a series of MD5 hash operations.
> To take full advantage of a given block cipher, the
> length of the passphrase should be at least equal to
> the cipher's blocksize. To skip this hashing operation
> and specify the key directly, pass a true value to the
> -literal_key option. In this case, you should choose a
> key of length exactly equal to the cipher's key length.
> You should also specify the IV yourself and a
> -header mode of 'none'.
I guess I was in a bit if a hurry or thinking too fast. I read the options
about the key and literal_key, but missed keysize and had already been
Googling for other possibilities. I have a bad tendency to start looking
in the tougher places first instead of the obvious.
Adding the keysize argument fixed it. In case the passwords change, I
used "keysize => length($pw)" for flexibility. I didn't need to try the
blocksize argument. It works fine if I specify the key size. My guess is
that in the older version, it compensated for that by just assuming the
keysize was whatever the key string length was.
> --------------------------
>
> Making a hash of a key phrase just generates a MD5 hash to be used
> as a key, that is the default.
I figured that and that's what I was avoiding.
> Your not doing that, so basically, the -keysize should be equal
> to the length of $pw, 8 bytes.
>
> To switch from literal key, you would have to initialize your Java objects
> to make hashes of the key.
Which would be a real pain. That's always possible for the next version,
but if I ever revisit crypto on this system I'll be upgrading it to use
PGP. I haven't done that so far because I have bypasses in so a person can
enter the password manually and PGP keys are kind of long!
Thanks! This took care if it. If I had read the Crypt::CBC docs more
closely before jumping off to Google, then I would have found it. I
appreciate your help and also you not rubbing in that I missed the obvious!
Thank you!
Hal
------------------------------
Date: Wed, 20 Aug 2008 13:18:45 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Repeating the array
Message-Id: <86skszbldm.fsf@lifelogs.com>
On Tue, 19 Aug 2008 22:55:22 -0700 (PDT) Arun <sajapuram.arun.prakash@gmail.com> wrote:
A> I just wanted small help here, i want to repeat an array for
A> every 30 seconds. lets us keep i want to send an array for every 30
A> seconds and also should be able to quit as per the user.
The only tricky part below is the read_key routine. You need to define
repeat_array() yourself.
Ted
#!/usr/bin/perl
use Every;
use Term::ReadKey;
while (1)
{
# check for user input and quit if it was 'q'
my $key = read_key();
last if (defined $key && $key eq 'q');
# repeat an array, whatever that means
repeat_array() if every(seconds=>30);
# print status
print "Hello again\n";
}
# read_key: read a single key from the keyboard
sub read_key
{
my $key;
ReadMode 3;
$key = ReadKey(1); # 1-second wait for a key; you can also use -1 for immediate return
ReadMode 0; # Reset tty mode before exiting
return $key;
}
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 1807
***************************************
