[32752] in Perl-Users-Digest
Perl-Users Digest, Issue: 4016 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Aug 17 09:09:35 2013
Date: Sat, 17 Aug 2013 06:09:04 -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 Sat, 17 Aug 2013 Volume: 11 Number: 4016
Today's topics:
Re: can some please help me , can we use perl for testi <visphatesjava@gmail.com>
Re: can some please help me , can we use perl for testi <suri.71@gmail.com>
How to force list context on passed args to built-in pa krystian.wojtas@gmail.com
Re: How to force list context on passed args to built-i <rweikusat@mobileactivedefense.com>
Re: How to force list context on passed args to built-i krystian.wojtas@gmail.com
Re: How to force list context on passed args to built-i <hjp-usenet3@hjp.at>
Re: How to force list context on passed args to built-i <hjp-usenet3@hjp.at>
Re: How to minimize server load when program is run <visphatesjava@gmail.com>
Re: openssl compatible key and IV calculation <ben@morrow.me.uk>
Re: openssl compatible key and IV calculation <ben@morrow.me.uk>
Re: openssl compatible key and IV calculation <ben@morrow.me.uk>
Re: openssl compatible key and IV calculation <derykus@gmail.com>
Re: openssl compatible key and IV calculation <rweikusat@mobileactivedefense.com>
Re: openssl compatible key and IV calculation <rweikusat@mobileactivedefense.com>
so is leanring perl programing and web apps a good way <visphatesjava@gmail.com>
Re: so is leanring perl programing and web apps a good <sbryce@scottbryce.com>
whats the hardest part of making a web app? <visphatesjava@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 15 Aug 2013 20:10:45 -0700 (PDT)
From: johannes falcone <visphatesjava@gmail.com>
Subject: Re: can some please help me , can we use perl for testing java applications.
Message-Id: <d14216d6-5b58-4f48-ada4-1b9c524c05c7@googlegroups.com>
On Tuesday, August 13, 2013 10:02:19 PM UTC-7, Suresh Macharla wrote:
> Can some one please let me know can we test java applications using perl. If yes, can you please help me with some links or tools that will help in this case.
>
> eagerly waiting for your replay.
>
>
>
> thanks in adv,
>
> Suresh
no
stop java
oracle must die
------------------------------
Date: Fri, 16 Aug 2013 12:14:17 -0700 (PDT)
From: Suresh Macharla <suri.71@gmail.com>
Subject: Re: can some please help me , can we use perl for testing java applications.
Message-Id: <db6df34f-70fc-4623-bc3c-9a159c3a6df0@googlegroups.com>
Dear Jens,
I my company there are 2 divisions one is for .net and other one is for java.
coming to java they will develop both client applications and server end services/ middle ware services.
So in this case how can i use perl in testing both client as well as server side modules.
thanks waiting for your replay.
On Wednesday, 14 August 2013 18:54:59 UTC+5:30, Jens Thoms Toerring wrote:
> Suresh Macharla <suri.71@gmail.com> wrote:
>
> > Can some one please let me know can we test java applications using perl. If
>
> > yes, can you please help me with some links or tools that will help in this
>
> > case. eagerly waiting for your replay.
>
>
>
> What kind of tests are you talking about?
>
>
>
> Regards, Jens
>
> --
>
> \ Jens Thoms Toerring ___ jt@toerring.de
>
> \__________________________ http://toerring.de
------------------------------
Date: Fri, 16 Aug 2013 03:45:56 -0700 (PDT)
From: krystian.wojtas@gmail.com
Subject: How to force list context on passed args to built-in pack function?
Message-Id: <47ee483d-c2fc-415c-811f-55ea80de3bf5@googlegroups.com>
Hi
The program I'm working on is creating a database using the built-in pack function. It needs to add a feature which makes some statistics about data usage by particular arrays.
The best approach I think is to use the Aspect module and insert some additional code after invoking the pack method. But as far as I see, hijacking the built-in function is not working. Could you confirm this?
In this case I prepared a wrapper function which is like this:
sub pack_wrapper { pack(@_); }
But it doesn't work. It looks like the pack function forces the list @_ to be passed in scalar context. In this case, pack gets the size of the array instead of its content.
The pack function hasn't a fixed number of arguments, so I cannot pass it directly like this:
sub pack_wrapper { pack($_[0], $_[1]); }
Probably I can use meta-programming to generate the code which invokes pack with all arguments explicitly depending on the list size. But such a workaround feels really awful for me.
Is it possible to pass my list @_ in list context to the pack function in some perl clean way?
Thanks for your answer and sorry if my question is obvious for you, I have already spent some time and cannot find the right solution.
Best regards,
Krystian
------------------------------
Date: Fri, 16 Aug 2013 12:08:16 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: How to force list context on passed args to built-in pack function?
Message-Id: <87r4dtnba7.fsf@sapphire.mobileactivedefense.com>
krystian.wojtas@gmail.com writes:
> The program I'm working on is creating a database using the built-in
> pack function. It needs to add a feature which makes some statistics
> about data usage by particular arrays.
>
> The best approach I think is to use the Aspect module and insert
> some additional code after invoking the pack method. But as far as I
> see, hijacking the built-in function is not working. Could you
> confirm this?
>
> In this case I prepared a wrapper function which is like this:
>
> sub pack_wrapper { pack(@_); }
>
> But it doesn't work.
That's because of the pack prototype. You could use
sub pack_wrapper { pack(shift, @_); }
instead.
------------------------------
Date: Fri, 16 Aug 2013 04:43:58 -0700 (PDT)
From: krystian.wojtas@gmail.com
Subject: Re: How to force list context on passed args to built-in pack function?
Message-Id: <bb1eeaff-3b91-4339-b6aa-f5e566801175@googlegroups.com>
> That's because of the pack prototype. You could use
>
>
>
> sub pack_wrapper { pack(shift, @_); }
>
>
>
> instead.
Thank you very much for your answer, it works perfectly now :)
------------------------------
Date: Fri, 16 Aug 2013 13:00:19 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: How to force list context on passed args to built-in pack function?
Message-Id: <slrnl0s1i5.8ne.hjp-usenet3@hrunkner.hjp.at>
On 2013-08-16 10:45, krystian.wojtas@gmail.com <krystian.wojtas@gmail.com> wrote:
> In this case I prepared a wrapper function which is like this:
>
> sub pack_wrapper { pack(@_); }
>
> But it doesn't work. It looks like the pack function forces the list
> @_ to be passed in scalar context.
Yes. pack expects a scalar and a list.
> In this case, pack gets the size of
> the array instead of its content.
>
> The pack function hasn't a fixed number of arguments, so I cannot pass
> it directly like this:
>
> sub pack_wrapper { pack($_[0], $_[1]); }
You can, however, do pass the rest of the arguments like this:
sub pack_wrapper { pack($_[0], @_[1..$#_]); }
However, I would prefer the more readable variant
sub pack_wrapper {
my ($template, @list) = @_;
pack($template, @list);
}
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Fri, 16 Aug 2013 15:26:19 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: How to force list context on passed args to built-in pack function?
Message-Id: <slrnl0sa3t.u0i.hjp-usenet3@hrunkner.hjp.at>
On 2013-08-16 11:43, krystian.wojtas@gmail.com <krystian.wojtas@gmail.com> wrote:
>> That's because of the pack prototype. You could use
>>
>> sub pack_wrapper { pack(shift, @_); }
>>
>> instead.
>
> Thank you very much for your answer, it works perfectly now :)
Do you understand why it works?
Will you still understand it in 6 months?
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Thu, 15 Aug 2013 20:19:44 -0700 (PDT)
From: johannes falcone <visphatesjava@gmail.com>
Subject: Re: How to minimize server load when program is run
Message-Id: <710b227a-3450-4d3c-b68f-17e34f095f84@googlegroups.com>
On Thursday, June 13, 2013 7:50:20 AM UTC-7, Justin C wrote:
> My web-hosts are running perl 5.8.8, other software there is of a
>
> similar age, and some things are missing (I wanted to 'nice' my
>
> program, but there is no 'nice').
>
>
>
> I have written a backup program to tar and gzip my entire directory
>
> tree on their site, and also to dump the db and add that to the tar.
>
> The program I have written runs one of my cores at 100% for two
>
> minutes, and uses almost 100MB RAM. If there is a way I'd like to
>
> reduce this load (as I can't 'nice' it).
>
>
>
> I haven't tried running the program yet, I don't want to get a
>
> bad name for maxing out the hardware. I've used core modules only,
>
> and I've used them as per documentation for the versions that were
>
> part of 5.8.8. I've pasted the code below, I'd be grateful for
>
> suggestions on how I could do the same while putting as little
>
> load on the server as possible.
>
>
>
> ~ $ cat bin/wp-backup.pl
>
> #!/usr/bin/perl
>
> use warnings;
>
> use strict;
>
> use Archive::Tar;
>
> use File::Find;
>
>
>
> # global vars
>
> chomp (my $now = `date +"%Y-%m-%d-%H%M"`);
>
> my $tar;
>
> my $file = "site.com.$now.tar.gz";
>
> my $backup_dir = '/var/sites/s/site.com/backups';
>
>
>
> create_archive();
>
> my $db = extract_db_data();
>
>
>
> $tar->add_files($db);
>
> $tar->write($archive, 9);
>
>
>
> sub archive_it {
>
> my $new_name = 'public_html/' . $_;
>
> (my $old_name = $File::Find::name) =~ s/^\///;
>
> $tar->add_files($File::Find::name);
>
> $tar->rename($old_name, $new_name);
>
> }
>
> sub create_archive {
>
> my $www_dir = '/var/sites/s/site.com/public_html';
>
>
>
> $tar = Archive::Tar->new; # declared in globals
>
> find(\&archive_it, $www_dir); # &archive_it adds it to the tar
>
> $tar->write($archive);
>
> }
>
> sub extract_db_data {
>
> my $db = {
>
> user => 'name',
>
> pass => 'password',
>
> name => 'db',
>
> file => "site.com.$now.sql",
>
> host => '1.0.0.0',
>
> };
>
>
>
> my @args = ('mysqldump', '--add-drop-table', '--complete-insert',
>
> '--extended-insert', '--hex-blob', "--host $db->{host}", "--user=$db->{user}",
>
> "--password=$db->{pass}", $db->{name}, '>', "$backup_dir/$db->{file}");
>
> system @args == 0 or die "problem running mysqldump: $!";
>
> return $db_file;
>
> }
>
>
>
> __END__
>
>
>
> Thankyou for any help or suggestions.
>
>
>
>
>
> Justin.
>
>
>
> --
>
> Justin C, by the sea.
bzip2 with -1 level is best combo of speed and compress on linux.
consider lvm snapshots for db backup
:)
use rsync or place it in http server and wget pull it
------------------------------
Date: Thu, 15 Aug 2013 22:10:45 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <lnsvda-qdo.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>
> And the difference between a brute-force attack which needs 52
> seconds to recover a password and one which needs 52 nanoseconds is
> practically irrelevant except if a 'large' number of passwords are
> supposed to be uncovered. And the algorithm may well need only 1s to
> recover the password when 52 $somethings can calculate different
> possibly correct results in parallell. Of course, two months from now,
> hardware or even software(!) capable of performing the '1s'
> calculation in a nanosecond will become available ...
Oh, for God's sake... go and read
http://en.wikipedia.org/wiki/Key_stretching , and stop assuming you can
solve complicated cryptographic problems in a few minutes in your head.
Ben
------------------------------
Date: Thu, 15 Aug 2013 22:07:22 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <ahsvda-qdo.ln1@anubis.morrow.me.uk>
Quoth Charles DeRykus <derykus@gmail.com>:
> On 8/15/2013 4:12 AM, Ben Morrow wrote:
> > Quoth Charles DeRykus <derykus@gmail.com>:
> >> On 8/14/2013 5:29 PM, Ben Morrow wrote:
> >>>
> >>> Well, all I did was pull the code out of Crypt::CBC.
> >>>
> >>> I don't know where this function is specified, but I have to say I'm a
> >>> little worried about the unconditional use of MD5. In the Kerberos
> >>> world, which I'm more familiar with, this function is called
> >>> 'string2key' and is considered cryptographically significant. Modern
> >>> Kerberos enctypes, in particular the AES enctypes, use a function from
> >>> PKCS#5, which uses SHA-1 rather than MD5 and performs many iterations to
> >>> increase the cost of a dictionary attack.
[...]
> >
> > ...that said, I've just looked at the source of 'openssl enc', and there
> > *is* an apparently-undocumented -md option to choose the hash function
> > to use for string2key, so it might be possible for the OP to switch to
> > SHA-1. However, there still isn't an option to add iterations, which is
> > almost more important. (The documentation for the underlying
> > EVP_BytesToKey even says that function is deprecated, and apps should
> > use the PKCS#5 function instead.)
>
> Thanks, I knew minimally that both would need to sync... but little more.
>
> With 1.0.1e, I did spot the -md option in 'man enc' but only the full
> option details inside openssl enc:
>
>
> -md the next argument is the md to use to create a key
> from a passphrase. One of md2, md5, sha or sha1
Ah, OK, so it was meant to be documented. I'm using 0.9.8y, since that's
what comes with my OS.
> $ openssl enc -a -aes-256-cbc -pass pass:"Secret Passphrase" -base64
> -md sha1 -P -S ab001d77079ba218
> salt=AB001D77079BA218
> key=890B75B7502649E8EF8EAF71B0A978F48229DCC4DE4F43F6825422694B311364
> iv =FF77D7B00DD3D950DC7F788E52EC8644
>
> Tweaking sub "aes_key_and_iv" to use Digest::SHA::sha1 does generate an
> identical key but, interestingly?, only a partial iv match:
>
> perl tmp.pl "Secret Passphrase" ab001d77079ba218
> key [890b75b7502649e8ef8eaf71b0a978f48229dcc4de4f43f6825422694b311364]
> iv [ff77d7b00dd3d950ec46c8be1f2ebf5e]
SHA-1 gives a 160-bit hash, so that matches as far as the end of the
second iteration. OpenSSL must use a slightly different algorithm after
the second iteration for SHA-1, or something.
In any case, one ought to be using PBKDF2, which is different again and
applies many iterations.
Ben
------------------------------
Date: Fri, 16 Aug 2013 01:34:47 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <7m80ea-9cq.ln1@anubis.morrow.me.uk>
Quoth Ben Morrow <ben@morrow.me.uk>:
> Quoth Charles DeRykus <derykus@gmail.com>:
>
> > $ openssl enc -a -aes-256-cbc -pass pass:"Secret Passphrase" -base64
> > -md sha1 -P -S ab001d77079ba218
> > salt=AB001D77079BA218
> > key=890B75B7502649E8EF8EAF71B0A978F48229DCC4DE4F43F6825422694B311364
> > iv =FF77D7B00DD3D950DC7F788E52EC8644
> >
> > Tweaking sub "aes_key_and_iv" to use Digest::SHA::sha1 does generate an
> > identical key but, interestingly?, only a partial iv match:
> >
> > perl tmp.pl "Secret Passphrase" ab001d77079ba218
> > key [890b75b7502649e8ef8eaf71b0a978f48229dcc4de4f43f6825422694b311364]
> > iv [ff77d7b00dd3d950ec46c8be1f2ebf5e]
>
> SHA-1 gives a 160-bit hash, so that matches as far as the end of the
> second iteration. OpenSSL must use a slightly different algorithm after
> the second iteration for SHA-1, or something.
So... I thought I'd have a look at this, just to see what was going on,
and after spending some time deciphering the apparently-intentionally-
unintelligible OpenSSL code I decided it ought to be doing the same
thing as the Perl. So I tried the Perl with Digest::SHA::sha1, and...
got the same result as with openssl. (Specifically, the same result as
you got with openssl above.)
So either your Digest::SHA is broken (which is possible: there are such
things as compiler bugs, and crypto code is more likely than most to
tickle them) or you changed something else.
Ben
------------------------------
Date: Thu, 15 Aug 2013 20:12:31 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <kuk5c9$696$1@speranza.aioe.org>
On 8/15/2013 5:34 PM, Ben Morrow wrote:
>
> Quoth Ben Morrow <ben@morrow.me.uk>:
>> Quoth Charles DeRykus <derykus@gmail.com>:
iteration for SHA-1, or something.
[...]
>
> So... I thought I'd have a look at this, just to see what was going on,
> and after spending some time deciphering the apparently-intentionally-
> unintelligible OpenSSL code I decided it ought to be doing the same
> thing as the Perl. So I tried the Perl with Digest::SHA::sha1, and...
> got the same result as with openssl. (Specifically, the same result as
> you got with openssl above.)
>
> So either your Digest::SHA is broken (which is possible: there are such
> things as compiler bugs, and crypto code is more likely than most to
> tickle them) or you changed something else.
Good grief... apologies. It was the latter:
< $d = sha1($d . $pass . $salt);
---
> $d = sha1($data . $pass . $salt);
--
Charles DeRykus
------------------------------
Date: Fri, 16 Aug 2013 11:16:20 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <874naqndor.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mobileactivedefense.com>:
>>
>> And the difference between a brute-force attack which needs 52
>> seconds to recover a password and one which needs 52 nanoseconds is
>> practically irrelevant except if a 'large' number of passwords are
>> supposed to be uncovered. And the algorithm may well need only 1s to
>> recover the password when 52 $somethings can calculate different
>> possibly correct results in parallell. Of course, two months from now,
>> hardware or even software(!) capable of performing the '1s'
>> calculation in a nanosecond will become available ...
>
> Oh, for God's sake... go and read
> http://en.wikipedia.org/wiki/Key_stretching
To which part is this supposed to apply? To the fact that
brute-forcing trivial passwords remains trivial no matter how much
time is wasted shuffling the bits contained in them? Or to the other
fact that what is 'a time-consuming calculation' today won't remain 'a
time-calculation' forever and probably not event for long, cf
Some excepts from the Wikipedia article:
The first deliberately slow password-based key derivation
function was called "CRYPT" and was published by Robert Morris
in 1978 for encrypting Unix passwords.
[...]
CRYPT(3) is now considered inadequate. The iteration count,
designed for the PDP-11 era, is too low, 12 bits of salt is an
inconvenience but does not stop precomputed dictionary
attacks,
-------
The commonly accepted Moore's law implies that computer speed
doubles about every 1.5 years. Under this assumption, every
1.5 years one more bit of key strength is plausibly
brute-forcible. This implies that 16 extra bits of strength is
worth about 161.5 = 24 years later cracking, but it also means
that the number of key stretching rounds a system uses should
be doubled about every 1.5 years to maintain the same level of
security.
------
An important consideration to be made is that CPU-bound hash
functions are still vulnerable to hardware
implementations. For example, the literature provides
efficient hardware implementations of SHA-1 in as low as 5000
gates, and able to produce a result in less than 400 clock cycles.
> and stop assuming you can solve complicated cryptographic problems
> in a few minutes in your head.
There's nothing complicate here. Exactly 262,144 different 'six byte
values' exist. Assuming a key derivation function which takes 1s to
execute, an exhaustive search of this space can be performed in about
3 days by a single computer with a single core CPU. 16 such computers
can do the same in about 4.5 hours. Using a key derivation function
which makes the computer calculating it come to a standstill for 2s
instead increases this to 9 hours. OTOH, using a random 7 byte
password would increase it to about 36 hours for 16 parallell
'crackers'. The obvious conclusion would be that 'obfuscate harder'
is way inferior to 'use higher quality input'.
------------------------------
Date: Fri, 16 Aug 2013 17:54:20 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: openssl compatible key and IV calculation
Message-Id: <87mwohr2yr.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
[...]
> There's nothing complicate here. Exactly 262,144 different 'six byte
> values' exist.
Except not accidentally messing up calculations as it seems :-). The
number of different 'six byte values' is really 281,474,976,710,656
(256**6) and not 8**6 and an exhaustive search of that with being able
to try one value per second would take a long time. But the basic idea
is nevertheless correct: Increasing the amount of entropy in the input
is vastly more efficient wrt making 'brute-forcing' complicated than
'using a more complicated bit shuffling algorithm'. Doing the example
again for 'three byte values' in order to get reasonably small
numbers:
256**3 is 16,777,216. For a random search, success would 'on average'
require trying half of the possible values. This would be 8,388,608.
At a speed of 1/s, this would take about 97 days. Decreasing the speed
to 0.5/s would mean 'about 194 days'. Using four bytes and the 1/s
scrambling algorithm instead would need about 24,855 days.
------------------------------
Date: Thu, 15 Aug 2013 20:17:47 -0700 (PDT)
From: johannes falcone <visphatesjava@gmail.com>
Subject: so is leanring perl programing and web apps a good way to get rich?
Message-Id: <53d2e9d1-471e-4bd6-80da-bb9a0a61b10b@googlegroups.com>
anyone here done it?
make over 200k?
tell me about it
------------------------------
Date: Thu, 15 Aug 2013 22:30:41 -0600
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: so is leanring perl programing and web apps a good way to get rich?
Message-Id: <kuk9tk$ubc$1@dont-email.me>
On 8/15/2013 9:17 PM, johannes falcone wrote:
> anyone here done it?
>
> make over 200k?
>
> tell me about it
Not really on topic for this group, but.....
Nobody is going to pay you 200k per year for learning Perl. If you are
going to make 200k per year, you need to do something that people are
willing to pay you that much for. Perl might be a good tool to use to do
that thing, or it may not. It depends on what it is that you will be
doing that will earn that much money.
So think this way: What can you do that someone is willing to pay you
200k to do? Is Perl a good tool to do that with? The what will you do
part of that question is a matter for discussion on a different
newsgroup. The is Perl a good tool for that part of the question might
be a good topic to discuss here once you have answered the other part of
the question.
Also off topic here, but...
Whether web apps are a good way to make money depends on whether enough
people are willing to pay enough money for access to your particular
app. We may be able to help you decide whether Perl is a good tool to
use to build that app. My idea for the killer app only earns half of
what you are shooting for, but Perl has been a great tool to build it.
------------------------------
Date: Thu, 15 Aug 2013 20:42:54 -0700 (PDT)
From: johannes falcone <visphatesjava@gmail.com>
Subject: whats the hardest part of making a web app?
Message-Id: <db1bbcad-77c5-4013-868d-7e15bdcf9375@googlegroups.com>
wondering?
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 4016
***************************************
