[30442] in Perl-Users-Digest
Perl-Users Digest, Issue: 1685 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jul 1 21:09:42 2008
Date: Tue, 1 Jul 2008 18:09:08 -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, 1 Jul 2008 Volume: 11 Number: 1685
Today's topics:
Re: My c code has stopped working: PL_errgv NULL? <fawaka@gmail.com>
Re: NDBM support <smallpond@juno.com>
Re: NDBM support <ben@morrow.me.uk>
Re: NDBM support <smallpond@juno.com>
Re: NDBM support xhoster@gmail.com
Re: NDBM support <smallpond@juno.com>
Re: NDBM support <ben@morrow.me.uk>
Re: NDBM support <No_4@dsl.pipex.com>
Re: Perl regular expression engine <hansmu@xs4all.nl>
RSA implementation, please comment. <rob@webteacher.com>
Re: Time::HiRes hell... <ben@morrow.me.uk>
Re: Time::HiRes hell... <fawaka@gmail.com>
Re: Time::HiRes hell... <Mark.Seger@hp.com>
Re: Time::HiRes hell... <Mark.Seger@hp.com>
Re: Time::HiRes hell... <ben@morrow.me.uk>
Re: Time::HiRes hell... <Mark.Seger@hp.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 01 Jul 2008 20:45:53 +0200
From: Leon Timmermans <fawaka@gmail.com>
Subject: Re: My c code has stopped working: PL_errgv NULL?
Message-Id: <d709e$486a7b61$89e0e08f$20012@news1.tudelft.nl>
On Tue, 01 Jul 2008 19:13:43 +0300, Georgios Petasis wrote:
> O/H Leon Timmermans έγραψε:
>
>
> Dear Leon,
>
> You can find the complete code at:
> http://ellogon.svn.sourceforge.net/viewvc/ellogon/trunk/lib/tclperl-3.2/
tclperl.c?revision=1&view=markup
>
> Yes, I am using perl_parse():
>
> PERL_SET_CONTEXT(my_perl);
> perl_construct(my_perl);
> perl_parse(my_perl, xs_init, 3, embedded, 0); perl_run(my_perl);
> eval_pv(code, 0);
> SvTRUE(ERRSV); <- crash :-(
>
> Regards,
>
> George
Hi,
Can you check the value of PL_errgv directly after perl_parse() and
perl_run() too?
Leon
------------------------------
Date: Tue, 01 Jul 2008 14:38:31 -0400
From: smallpond <smallpond@juno.com>
Subject: Re: NDBM support
Message-Id: <c2c6f$486a79b5$2956@news.teranews.com>
szr wrote:
> smallpond wrote:
>> alex.turchin@gmail.com wrote:
>>> On Jun 30, 3:08 pm, Mark Clements
>>> <mark.clementsREMOVET...@wanadoo.fr> wrote:
>>>> alex.turc...@gmail.com wrote:
>>>>> I have an old and rather large (thousands of lines of code) piece
>>>>> of perl software that utilizes (in numerous places) NDBM databases,
>>>>> including dbmopen() etc. calls. This code has now been moved by the
>>>>> website administrator to a different UNIX platform that does not
>>>>> support NDBM.
>>>>> Unfortunately I do not have the resources to completely rewirte the
>>>>> code to utilize a different database. Even more importantly, all of
>>>>> the data the software uses (unique to the software and took months
>>>>> of work to enter) is in the NDBM format.
>>>>> I am therefore looking for a way to obtain perl support for the
>>>>> NDBM format and corresponding function calls (dbmopen, dbmclose)
>>>>> on a system that does not natively support them. Any thoughts
>>>>> would be greatly appreciated!
>>>> Hmmm.
>>>>
>>>> http://perldoc.perl.org/functions/dbmopen.html
>>>>
>>>> (quoted)
>>>> **
>>>> You can control which DBM library you use by loading that library
>>>> before you call dbmopen():
>>>>
>>>> use DB_File;
>>>> dbmopen(%NS_Hist, "$ENV{HOME}/.netscape/history.db")
>>>> or die "Can't open netscape history file: $!";
>>>>
>>>> **
>>>>
>>>> Can you not install NDBM_File and add a
>>>>
>>>> use NDBM_File;
>>>>
>>>> to the script(s)?
>>>>
>>>> http://search.cpan.org/~rgarcia/perl-5.10.0/ext/NDBM_File/NDBM_File.pm
>>>>
>>>> Mark- Hide quoted text -
>>>>
>>>> - Show quoted text -
>>> Unfortunately no longer have access to the old platform so can't dump
>>> the files out :(
>>>
>>> With respect to using NDBM_File - will that work in absence of ndbm
>>> support on the underlying UNIX platform? I don't have admin
>>> privileges to the system and have to beg the admin to install stuff
>>> like Perl modules for me - would like to minimize trial & error if
>>> possible if you know what I mean :)
>>>
>>> Thanks!
>>> Alex
>>
>> NDBM_File is standard with perl 5.10 and is not available for earlier
>> versions of perl.
>
> Not true, it works in both 5.8.8 and 5.10.0 for me (see below.)
>
>> perl --version
>>
>> This is perl, v5.10.0 built for i686-linux
>>
>> perl -e 'use NDBM_File; dbmopen(%h, "foo", 0666)'
>>
>> Creates two files: foo.dir and foo.pag
>> file foo.dir
>> foo.dir: GNU dbm 1.x or ndbm database, little endian
>
> That works for 5.8.8 as well:
>
> $ perl5.8.8 -e 'use NDBM_File; dbmopen(%h, "foo5.8.8", 0666)'
>
> $ perl5.10.0 -e 'use NDBM_File; dbmopen(%h, "foo5.10.0", 0666)'
>
>
> They both create the two files you mentioned:
>
> -rw-r--r-- 2 root root 12288 Jun 30 15:36 foo5.8.8.dir
> -rw-r--r-- 2 root root 12288 Jun 30 15:36 foo5.8.8.pag
> -rw-r--r-- 2 root root 12288 Jun 30 15:36 foo5.10.0.dir
> -rw-r--r-- 2 root root 12288 Jun 30 15:36 foo5.10.0.pag
>
>
No doubt I'm confused. Can you point me to the 5.8.8. version on CPAN?
** Posted from http://www.teranews.com **
------------------------------
Date: Tue, 1 Jul 2008 20:02:05 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: NDBM support
Message-Id: <dibqj5-nvt.ln1@osiris.mauzo.dyndns.org>
Quoth smallpond <smallpond@juno.com>:
>
[NDBM_File]
>
> No doubt I'm confused. Can you point me to the 5.8.8. version on CPAN?
http://search.cpan.org/~nwclark/perl-5.8.8/ext/NDBM_File/NDBM_File.pm
Where did you look?
Ben
--
I must not fear. Fear is the mind-killer. I will face my fear and
I will let it pass through me. When the fear is gone there will be
nothing. Only I will remain.
ben@morrow.me.uk Frank Herbert, 'Dune'
------------------------------
Date: Tue, 01 Jul 2008 15:27:00 -0400
From: smallpond <smallpond@juno.com>
Subject: Re: NDBM support
Message-Id: <341aa$486a8515$19088@news.teranews.com>
Ben Morrow wrote:
> Quoth smallpond <smallpond@juno.com>:
> [NDBM_File]
>> No doubt I'm confused. Can you point me to the 5.8.8. version on CPAN?
>
> http://search.cpan.org/~nwclark/perl-5.8.8/ext/NDBM_File/NDBM_File.pm
>
> Where did you look?
>
> Ben
>
I don't see a link on that page to download the module, just all of perl 5.8.8.
The link to source just gives the perl code, without the C code, test code, etc.
When I use the CPAN routine to install NDBM_File, it attempts to download perl
5.10.0. What are you seeing that I'm not?
** Posted from http://www.teranews.com **
------------------------------
Date: 01 Jul 2008 19:55:03 GMT
From: xhoster@gmail.com
Subject: Re: NDBM support
Message-Id: <20080701155508.810$9V@newsreader.com>
smallpond <smallpond@juno.com> wrote:
> Ben Morrow wrote:
> > Quoth smallpond <smallpond@juno.com>:
> > [NDBM_File]
> >> No doubt I'm confused. Can you point me to the 5.8.8. version on
> >> CPAN?
> >
> > http://search.cpan.org/~nwclark/perl-5.8.8/ext/NDBM_File/NDBM_File.pm
> >
> > Where did you look?
> >
> > Ben
> >
>
> I don't see a link on that page to download the module, just all of perl
> 5.8.8.
That's because it is a core module. "all of perl 5.8.8" is where the
module lives.
> The link to source just gives the perl code, without the C code,
> test code, etc. When I use the CPAN routine to install NDBM_File, it
> attempts to download perl 5.10.0. What are you seeing that I'm not?
If you got a 5.8.8 that doesn't support NDBM, then I think you need to
rebuild your perl.
You can't just add it on as an afterthought, or at least not easily.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Tue, 01 Jul 2008 16:14:34 -0400
From: smallpond <smallpond@juno.com>
Subject: Re: NDBM support
Message-Id: <19bbf$486a903b$766@news.teranews.com>
xhoster@gmail.com wrote:
> smallpond <smallpond@juno.com> wrote:
>> Ben Morrow wrote:
>>> Quoth smallpond <smallpond@juno.com>:
>>> [NDBM_File]
>>>> No doubt I'm confused. Can you point me to the 5.8.8. version on
>>>> CPAN?
>>> http://search.cpan.org/~nwclark/perl-5.8.8/ext/NDBM_File/NDBM_File.pm
>>>
>>> Where did you look?
>>>
>>> Ben
>>>
>> I don't see a link on that page to download the module, just all of perl
>> 5.8.8.
>
> That's because it is a core module. "all of perl 5.8.8" is where the
> module lives.
>
>> The link to source just gives the perl code, without the C code,
>> test code, etc. When I use the CPAN routine to install NDBM_File, it
>> attempts to download perl 5.10.0. What are you seeing that I'm not?
>
> If you got a 5.8.8 that doesn't support NDBM, then I think you need to
> rebuild your perl.
>
> You can't just add it on as an afterthought, or at least not easily.
>
>
> Xho
>
Further research says that for whatever reason, the Fedora folks delete
NDBM_File, and just include GDBM_File and DB_File in their perl build.
I have it in 5.10 because I built it from source. Yet another
reason not to use Fedora, I suppose.
** Posted from http://www.teranews.com **
------------------------------
Date: Tue, 1 Jul 2008 21:39:48 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: NDBM support
Message-Id: <k9hqj5-gno1.ln1@osiris.mauzo.dyndns.org>
Quoth smallpond <smallpond@juno.com>:
> Ben Morrow wrote:
> > Quoth smallpond <smallpond@juno.com>:
> > [NDBM_File]
> >> No doubt I'm confused. Can you point me to the 5.8.8. version on CPAN?
> >
> > http://search.cpan.org/~nwclark/perl-5.8.8/ext/NDBM_File/NDBM_File.pm
> >
> > Where did you look?
>
> I don't see a link on that page to download the module, just all of
> perl 5.8.8. The link to source just gives the perl code, without the C
> code, test code, etc. When I use the CPAN routine to install
> NDBM_File, it attempts to download perl 5.10.0. What are you seeing
> that I'm not?
As I said before, it is not now and has never been possible to install any
of the *DBM_File modules from CPAN. They have come with perl since
v5.000, and cannot be upgraded without upgrading perl. If you don't have
NDBM_File, this means Configure failed to find <ndbm.h> when your perl
was built; to install it, you need to locate and install some
appropriate <ndbm.h> and -lndbm and rebuild perl.
There are lots of other modules in this position: Carp, Socket,
File::Find, and most of the pragmata, for instance. p5p are moving
towards getting modules out of the core and onto CPAN, since it makes
upgrading possible, but someone has to volunteer to maintain the module
(and have some improvement they want to make).
The fact that the CPAN shell will attempt to upgrade perl if you ask for
a module that only exists in the core is, IMHO, a bug. Upgrading perl is
not within the scope of CPAN.pm, and I seriously doubt it has ever
worked correctly.
Ben
--
The Earth is degenerating these days. Bribery and corruption abound.
Children no longer mind their parents, every man wants to write a book,
and it is evident that the end of the world is fast approaching.
Assyrian stone tablet, c.2800 BC ben@morrow.me.uk
------------------------------
Date: Wed, 02 Jul 2008 00:48:53 +0100
From: Big and Blue <No_4@dsl.pipex.com>
Subject: Re: NDBM support
Message-Id: <-q6dndfjue34X_fVRVnytAA@pipex.net>
Ben Morrow wrote:
>
> As I said before, it is not now and has never been possible to install any
> of the *DBM_File modules from CPAN. They have come with perl since
> v5.000, and cannot be upgraded without upgrading perl.
I'm sure it would be possible to hack in a build if one wished to do
so. It's just code for a module.
> If you don't have
> NDBM_File, this means Configure failed to find <ndbm.h> when your perl
> was built; to install it, you need to locate and install some
> appropriate <ndbm.h> and -lndbm and rebuild perl.
NDBM was proprietary code (of AT&T?) and so only ever appeared in
commercial Unix OSes. It's not been in Linux, that I know of, except
for the NDBM API included with GNU DBM (which is an optional part of the
build). And when I checked that didn't use NDBM format files.
That was several years ago - things may have changed.
--
Just because I've written it doesn't mean that
either you or I have to believe it.
------------------------------
Date: Tue, 01 Jul 2008 23:13:24 +0200
From: Hans Mulder <hansmu@xs4all.nl>
Subject: Re: Perl regular expression engine
Message-Id: <486a9e1e$0$14351$e4fe514c@news.xs4all.nl>
Ben Morrow wrote:
> Quoth Ricardo <rvelosoo@gmail.com>:
>> I was wondering if someone could point me some ref on what algorithms
>> are used by perl to find matches between regular expressions and
>> text? Is it a dfa?
>
> No, it's a form of NFA, to allow capturing. The only real reference for
> the algorithms used by perl is reg{comp,exec}.c in the perl source, but
> I *really* wouldn't recommend starting there :). Find a good reference
> on POSIX regular expression implementations.
If you really want to know how it's implemented, there's
http://search.cpan.org/~rgarcia/perl-5.10.0/pod/perlreguts.pod
This is easier to understand then the C code. It still assumes you
already know what regular expressions do and want to know more about
how it's done.
Hope this helps,
-- HansM
------------------------------
Date: Tue, 1 Jul 2008 17:24:08 -0700 (PDT)
From: Rob <rob@webteacher.com>
Subject: RSA implementation, please comment.
Message-Id: <abf5b395-34f2-4723-ae6f-427f9f984489@f24g2000prh.googlegroups.com>
Hi All;
I've come up with a solution and I'd like some feedback on whether or
not it is secure.
SYNOPSIS: Is Crypt::RSA secure acceptable in open source if the
private key password is in a browser cookie?
DETAILS:
We're running a pretty basic LAMPS system with MySQL 5.1 and Perl 5.8.
The client asked me to devise "a secure way to save credit card
numbers in the sales database". Every paper I've read recommends
saving the card numbers off site or not at all, but in this case the
the client is a middle-man who collects the sales information
(including card numbers) in one place, and needs to pull up the entire
customer record including card data in a back-office setting using a
secure server.
Most encryption and decryption schemas I came up with had the same
problem -- open source. Any method that would encrypt the data in
MySQL and be decrypted by Perl could be read if someone were to gain
access to the server. The MySQL login script could also be read in
open source, so I feared that no matter how well we encrypted the
data, a hacker would only have to follow the script to gain access to
thousands of card numbers.
The staff members will be opening hundreds of orders per day, and they
need the encryption to be fast and transparent with no inconvenience
at all to the legitimate users.
Here is the solution I came up with:
1. Using Crypt::RSA I created a 256 bit public and private key with a
63 character password. Both keys are saved on the server, but the
password is not.
2. The credit card number is a blob field. When a new order is
entered, it is encrypted with the public key and saved.
3. Authorized users will use a JavaScript page to set a cookie with
the private key's password. It will be a session only cookie, which is
removed automatically when the user logs out of the database
interface.
4. If the cookie is present, the script will use its value to open the
private key and display the card info. Otherwise, it only displays
************.
I believe that this solution is secure because the private key
password is never saved on the server. A hacker would have to gain
access to an authorized user's PC to gain the password. I am not sure
how difficult it is to crack a 256 bit private key with a 63 character
pass. There is plenty of documentation on how hard it is to brute
force the entire key, but not much I could find on the password.
If you can see a security hole with this method, please reply.
Thanks,
Rob
------------------------------
Date: Tue, 1 Jul 2008 19:07:19 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Time::HiRes hell...
Message-Id: <nb8qj5-4ur.ln1@osiris.mauzo.dyndns.org>
Quoth Mark Seger <Mark.Seger@hp.com>:
>
> I'm now starting to get bug reports against systems with glibc 2.5 on
> them and what I plan to do with my next release if check the versions of
> HiRes and glibc and if they're incompatible point the user to cpan and
> tell them to install a newer version of HiRes. Seemed to work great
> until I tried to install a new version of HiRes. When I did my 'make
> install', it told me:
>
> [root@cag-dl585-01 Time-HiRes-1.9715]# make install
> Files found in blib/arch: installing files in blib/lib into architecture
> dependent library tree
> Writing
> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/HiRes/.packlist
> Appending installation info to
> /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/perllocal.pod
>
> and I discovered I now have both the old and new version of HiRes
> installed.
Is the RHEL? RedHat are know to have messed up perl's @INC ordering in
many of their perl packages. Unfortunately there's not much you can do
to fix that...
> But what really makes this awful when I try to use HiRes
> perl loads the older one. Clearly it's a library search path issue but
> given this can run on any distro I can't make any assumptions about
> where the module actually gets installed.
Where is the old copy? Is it the version installed as part of 5.8.8, or
some other version installed by your package manager?
On my system I have
/usr/local/lib/perl5/5.8.8/mach/Time/HiRes.pm
/usr/local/lib/perl5/site_perl/5.8.8/mach/Time/HiRes.pm
but since my @INC is
/usr/local/lib/perl5/5.8.8/BSDPAN
/usr/local/lib/perl5/site_perl/5.8.8/mach
/usr/local/lib/perl5/site_perl/5.8.8
/usr/local/lib/perl5/site_perl
/usr/local/lib/perl5/5.8.8/mach
/usr/local/lib/perl5/5.8.8
.
this isn't a problem. 'site' should come before 'vendor' should come
before 'core', for this reason.
> I'm not sure what the best solution to this is. Is there an easy way to
> remove the older version? Ultimately I want to be able to tell users of
> my tool how to get HiRes properly installed and they may not even be
> perl users or developers so the solution needs to be very simple.
# make install UNINST=1
will remove any other versions it can find that might conflict. This
isn't the default because it could be dangerous on systems with multiple
versions of perl installed and a carefully-constructed @INC (or
networked filesystems serving machines with multiple versions of perl),
but on systems with only one perl it's safe. Of course the package
manager will probably complain that whichever package HiRes.pm belonged
to is now corrupt. :(
Ben
--
The cosmos, at best, is like a rubbish heap scattered at random.
Heraclitus
ben@morrow.me.uk
------------------------------
Date: Tue, 01 Jul 2008 20:41:50 +0200
From: Leon Timmermans <fawaka@gmail.com>
Subject: Re: Time::HiRes hell...
Message-Id: <69f55$486a7a6e$89e0e08f$20012@news1.tudelft.nl>
On Tue, 01 Jul 2008 12:36:50 -0400, Mark Seger wrote:
> I'd posted a note on HiRes earlier but things seem to be getting more
> complicated. Here are the facts as I understand them:
>
> - versions of HiRes older than 1.91 call setitimer with the entire time
> interval as usecs even if > 1sec. This is clearly in violation of the
> calling interface to setitimer, but with glibc versions <2.4 it still
> works correctly as I've been successfully using this for over 5 years. -
> with glibc 2.4, you get random results if the time >4 seconds - with
> glibc 2.5, you get failures but is seems only during boot!
Actually, it seems it isn't glibc but the linux kernel itself that
changed behavior (in release 2.6.21).
> I know this sounds odd, but I tried running a test that did alarms > 1
> second as an inet.d script and watched the console. I got errors while
> the system was booting and once it finished, the error messages stopped.
That's strange indeed.
> and I discovered I now have both the old and new version of HiRes
> installed. But what really makes this awful when I try to use HiRes
> perl loads the older one. Clearly it's a library search path issue but
> given this can run on any distro I can't make any assumptions about
> where the module actually gets installed.
>
> I'm not sure what the best solution to this is. Is there an easy way to
> remove the older version? Ultimately I want to be able to tell users of
> my tool how to get HiRes properly installed and they may not even be
> perl users or developers so the solution needs to be very simple.
>
You could try saying:
use Time::HiRes 1.91 qw/sleep gettimeofday/;
I'm not quite sure that's going to work though, the documentation isn't
clear on whether it will give up after rejecting the old version or
whether it will search on.
Alternatively, you could use plain old sleep. Inaccurate but reliable...
Leon
------------------------------
Date: Tue, 01 Jul 2008 14:49:20 -0400
From: Mark Seger <Mark.Seger@hp.com>
To: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Time::HiRes hell...
Message-Id: <486A7C30.8090108@hp.com>
> Where is the old copy? Is it the version installed as part of 5.8.8, or
> some other version installed by your package manager?
[root@hadesn0 ~]# find /usr | grep HiRes
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/HiRes
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/HiRes/HiRes.so
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/Time/HiRes.pm
>
> # make install UNINST=1
>
> will remove any other versions it can find that might conflict. This
> isn't the default because it could be dangerous on systems with multiple
> versions of perl installed and a carefully-constructed @INC (or
> networked filesystems serving machines with multiple versions of perl),
> but on systems with only one perl it's safe. Of course the package
> manager will probably complain that whichever package HiRes.pm belonged
> to is now corrupt. :(
very cool! thanks...
-mark
------------------------------
Date: Tue, 01 Jul 2008 14:55:50 -0400
From: Mark Seger <Mark.Seger@hp.com>
Subject: Re: Time::HiRes hell...
Message-Id: <g4dujn$n5c$1@usenet01.boi.hp.com>
> I'm not quite sure that's going to work though, the documentation isn't
> clear on whether it will give up after rejecting the old version or
> whether it will search on.
It looks like Ben's trick of installing with the make switch UNINST=1
did the trick
> Alternatively, you could use plain old sleep. Inaccurate but reliable...
actually, you really don't want to get me started on this one 8-)
but there are so many broken monitoring utilities because they do sleeps
when they could/should be handling time much more accurately. there are
some very large clusters running collectl and all taking samples at
pretty tightly synchronized times, literally every 10 seconds day in and
day out, all using ntp of course, with virtually no drift. how else is
one to try and correlate data across hundreds of nodes if they're not
all synchronized? actually if you want to try it out for yourself it's
on sourceforge
-mark
------------------------------
Date: Tue, 1 Jul 2008 19:59:57 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Time::HiRes hell...
Message-Id: <debqj5-nvt.ln1@osiris.mauzo.dyndns.org>
Quoth Leon Timmermans <fawaka@gmail.com>:
> On Tue, 01 Jul 2008 12:36:50 -0400, Mark Seger wrote:
>
> You could try saying:
>
> use Time::HiRes 1.91 qw/sleep gettimeofday/;
>
> I'm not quite sure that's going to work though, the documentation isn't
> clear on whether it will give up after rejecting the old version or
> whether it will search on.
It will fail if the first copy found isn't the correct version. See also
only::latest on CPAN.
Ben
--
If you put all the prophets, | You'd have so much more reason
Mystics and saints | Than ever was born
In one room together, | Out of all of the conflicts of time.
ben@morrow.me.uk The Levellers, 'Believers'
------------------------------
Date: Tue, 01 Jul 2008 15:00:45 -0400
From: Mark Seger <Mark.Seger@hp.com>
Subject: Re: Time::HiRes hell...
Message-Id: <g4dusu$pcl$1@usenet01.boi.hp.com>
just got another report from another user - according to him the
messages went away once the ntpd service started. any thoughts?
-mark
------------------------------
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 1685
***************************************
