[32347] in Perl-Users-Digest
Perl-Users Digest, Issue: 3614 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Feb 19 16:09:21 2012
Date: Sun, 19 Feb 2012 13:09:05 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 19 Feb 2012 Volume: 11 Number: 3614
Today's topics:
Re: Elegant ways to convert '' or 'number' to a number <ben@morrow.me.uk>
Re: Elegant ways to convert '' or 'number' to a number (Tim McDaniel)
Re: Elegant ways to convert '' or 'number' to a number <rweikusat@mssgmbh.com>
Re: Elegant ways to convert '' or 'number' to a number <hjp-usenet2@hjp.at>
Re: Elegant ways to convert '' or 'number' to a number <rweikusat@mssgmbh.com>
Re: File::Slurp and reading files in general <ben@morrow.me.uk>
Re: File::Slurp and reading files in general <rweikusat@mssgmbh.com>
Re: File::Slurp and reading files in general <rweikusat@mssgmbh.com>
Re: File::Slurp and reading files in general <hjp-usenet2@hjp.at>
rm .cpan? <wpmccormick@just_about_everywhere.com>
Re: rm .cpan? <ben@morrow.me.uk>
Re: rm .cpan? <wpmccormick@just_about_everywhere.com>
Re: rm .cpan? <ben@morrow.me.uk>
Re: sorting unicode file under windows command line <ehabaziz2001@gmail.com>
Re: sorting unicode file under windows command line <jimsgibson@gmail.com>
Re: Using loop labels and iterating. <jwkrahn@example.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 17 Feb 2012 19:44:55 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Elegant ways to convert '' or 'number' to a number
Message-Id: <nan219-eg2.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>
> Somethingh like
>
> SELECT
> case column
> when '' then 0
> else column
> end
> from table
>
> should work, though.
Except this has no advantage over
$x = $x eq "" ? 0 : $x;
If you end up in a position where you have no choice but to bodge your
data, it's usually easier to do that bodging in Perl than in something
else like SQL. Perl, after all, was designed for the job.
Ben
------------------------------
Date: Fri, 17 Feb 2012 20:15:52 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Elegant ways to convert '' or 'number' to a number
Message-Id: <jhmcho$j4p$1@reader1.panix.com>
In article <slrnjjt5ql.sif.hjp-usenet2@hrunkner.hjp.at>,
Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>Tim already wrote (unless I misunderstood him), that the value is
>actually "", not undef. DBI always returns undef for NULL, so that
>wouldn't help. (This also means that the column has almost certainly
>a varchar type, not a number type, which hints at a deeper database
>design problem - but unfortunately we often have to live with
>databases as they are and can't fix them).
In particular, this is Oracle. As I understand it, it implements
varchar NULL as a null string. It may be DBI, or the database
wrappers we've put around it, or other functions around them, but my
cow-orker reported that it was indeed a null string when he got it.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Fri, 17 Feb 2012 21:13:58 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Elegant ways to convert '' or 'number' to a number
Message-Id: <87ipj55fjd.fsf@sapphire.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
[...]
> Contrary to what Rainer probably thinks numbers and strings aren't
> the same in Perl
Assumptions you make about other people's thoughts are YOUR thoughts.
------------------------------
Date: Sat, 18 Feb 2012 00:16:42 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Elegant ways to convert '' or 'number' to a number
Message-Id: <slrnjjtnur.eev.hjp-usenet2@hrunkner.hjp.at>
On 2012-02-17 20:15, Tim McDaniel <tmcd@panix.com> wrote:
> In article <slrnjjt5ql.sif.hjp-usenet2@hrunkner.hjp.at>,
> Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>>Tim already wrote (unless I misunderstood him), that the value is
>>actually "", not undef. DBI always returns undef for NULL, so that
>>wouldn't help. (This also means that the column has almost certainly
>>a varchar type, not a number type, which hints at a deeper database
>>design problem - but unfortunately we often have to live with
>>databases as they are and can't fix them).
>
> In particular, this is Oracle. As I understand it, it implements
> varchar NULL as a null string.
Nope, its the other way around: You cannot store an empty string in an
Oracle varchar2, it's automatically converted to NULL. Actually, it
looks like '' is just another notation for NULL in Oracle: You can
insert '' into a numeric column (resulting in a null value) and neither
''='' nor ''!='' is true).
> It may be DBI,
DBI returns undef if the value is null.
> or the database wrappers we've put around it, or other functions
> around them,
Probably. So you probably should hunt down that function that converts
undef to '' and check whether its really supposed to do that and whether
its the right function for the problem.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Sat, 18 Feb 2012 02:52:45 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Elegant ways to convert '' or 'number' to a number
Message-Id: <87ehtssvia.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>
> [...]
>
>> Contrary to what Rainer probably thinks numbers and strings aren't
>> the same in Perl
>
> Assumptions you make about other people's thoughts are YOUR thoughts.
... and isn't it amazing that one can get as old as this guy probably
is and still not outgrow his "young, dumb and full of cum" manners?
This person has probably been living off other people's taxes for
longer than I had the mispleasure to be aware of him, this being a
good ten years, and despite that he must be close to a pension most
people could only dream of, he still sees the necessity to 'fight
competition' ...
------------------------------
Date: Fri, 17 Feb 2012 21:39:26 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: File::Slurp and reading files in general
Message-Id: <e1u219-es3.ln1@anubis.morrow.me.uk>
Quoth Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net>:
>
> Talking about this:
>
> what is actually the advantage of sysread over the "Perl way" of reading
> from a file with code like $result = <$fileHande> (or @result =
> <$fileHandle>, depending on wantarray)?
In theory it can be faster. Perl's normal PerlIO layer puts a layer of
buffering between your program and the kernel; if you care a lot about
performance you probably want to avoid that and do the buffering
yourself more intelligently. Most of the time this will make no
difference and isn't worth worrying about.
> To slurp, I simply undef $/ and
> everything seems fine... I have never used sysread in Perl - should I
> consider using it?
No, not unless you have a reason to. I use File::Slurp because (and only
because) it has a clean, simple interface for getting a file into a
string, without needing to mess about opening filehandles and setting
globals.
> I didn't expect such a long code for some "simple" thing like reading in
> a file, especially not a comment telling me it is using "DEEP DARK MAGIC".
The DEEP DARK MAGIC is specifically to do with slurping the DATA
filehandle. This is harder than you might think to do correctly, and
it's useful to know it will Just Work. (Using the untaint flag to
identify a DATA handle is a hack, hence the comment.)
> As I am usually using an "enterprise" Linux distribution (RHEL clone), I
> still need to make scripts compatible with 5.8.8 where File::Slurp is
> not a core module...
File::Slurp is never a core module (or, at least, not to date). However,
I'm sure RHEL has a package for it.
Ben
------------------------------
Date: Fri, 17 Feb 2012 22:26:40 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: File::Slurp and reading files in general
Message-Id: <878vk15c67.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
[...]
> No, not unless you have a reason to. I use File::Slurp because (and only
> because) it has a clean, simple interface for getting a file into a
> string, without needing to mess about opening filehandles and setting
> globals.
Provided that's really just what you want, consider using this:
sub slurp
{
my $fh;
open($fh, '<', $_[0]) or die("open: $_[0]: $!");
local $/ unless wantarray();
return <$fh>;
}
That's less buggy (because it leaves the intricacies of dealing with
system specific I/O to perl) and possibly even faster (again because
it uses features perl already has).
------------------------------
Date: Fri, 17 Feb 2012 22:45:37 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: File::Slurp and reading files in general
Message-Id: <874nup5bam.fsf@sapphire.mobileactivedefense.com>
Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net> writes:
>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>
>> [...]
>>
>>> OTOH, the source code of that was 'an interesting read'.
>
> Talking about this:
>
> what is actually the advantage of sysread over the "Perl way" of reading
> from a file with code like $result = <$fileHande> (or @result =
> <$fileHandle>, depending on wantarray)? To slurp, I simply undef $/ and
> everything seems fine... I have never used sysread in Perl - should I
> consider using it?
It bypasses the Perl I/O buffering mechanism, including any
translations layers etc which might be active as part of that. I
wouldn't use it for reading 'text files'. It is, however, useful when
more control about the actual I/O operations performed by a program is
required than the read-in-advance/ write-behind buffering mechanism
offers. This would usually either be the case if the I/O is actually
'real-time' IPC, eg, when the program is acting as a server on an
AF_UNIX datagram socket or when reliability is an important concern,
eg, when doing 'atomic updates' of files which must (to the degree the
application can guarantee this) remain in a consistent state even when
power suddenly goes away. Since "whining about the evil filesystem"
doesn't really help to solve the problem, this required a multi-step
procedure where one stop must have been completed before the next one
commences.
------------------------------
Date: Sat, 18 Feb 2012 00:35:32 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: File::Slurp and reading files in general
Message-Id: <slrnjjtp27.eev.hjp-usenet2@hrunkner.hjp.at>
On 2012-02-17 16:43, Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net> wrote:
> Am 17.02.2012 16:46, schrieb Rainer Weikusat:
>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>
>> [...]
>>
>>> OTOH, the source code of that was 'an interesting read'.
>
> Talking about this:
>
> what is actually the advantage of sysread over the "Perl way" of reading
> from a file with code like $result = <$fileHande> (or @result =
><$fileHandle>, depending on wantarray)?
I'll just quote from a posting I wrote about 2 years ago (incidentally
in reply to Uri Guttman's claim that sysread is faster):
[...]
| So I grabbed the server with the fastest disks I had access to (disk
| array of SSDs), created a file with 400 million lines of 80 characters
| (plus newline) each and ran some benchmarks:
|
| method time speed (MB/s)
| ----------------------------------------------
| perlio $/ = "\n" 2:35.12 209
| perlio $/ = \4096 1:35.36 340
| perlio $/ = \1048576 1:35.25 340
| sysread bs = 4096 1:35.28 340
| sysread bs = 1048576 1:35.18 340
|
| The times are the median of three runs. Times between the runs differed
| by about 1 second, so the difference between reading line by line and
| block by block is significant, but the difference between perlio and
| sysread or between different blocksizes isn't.
|
| I was a bit surprised that reading line by line was so much slower than
| blockwise reading. Was it because of the higher loop overhead (81 bytes
| read per loop instead of 4096 means 50 times more overhead) or because
| splitting a block into lines is so expensive?
|
| So I did another run of benchmarks with different block sizes:
|
| method block user system cpu total
| read_file_by_perlio_block 4096 0.64s 26.87s 31% 1:27.91
| read_file_by_perlio_block 2048 1.48s 28.65s 34% 1:28.56
| read_file_by_perlio_block 1024 5.14s 29.03s 37% 1:30.59
| read_file_by_perlio_block 512 11.98s 31.33s 47% 1:31.22
| read_file_by_perlio_block 256 26.84s 33.13s 61% 1:36.85
| read_file_by_perlio_block 128 43.53s 29.05s 71% 1:41.66
| read_file_by_perlio_block 64 77.26s 28.16s 88% 1:59.70
| read_file_by_line 104.68s 28.01s 93% 2:22.34
|
| (the times are a bit lower now because here the system was idle while it
| had a (relatively constant) load during the first batch)
|
| As expected elapsed time as well as CPU time increases with shrinking
| block size. However, even at 64 bytes, reading in blocks is still 20%
| faster than reading in lines, even though the loop is now executed 27%
| more often.
|
| Conclusions:
|
| * The difference between sysread and blockwise <> isn't even measurable.
|
| * Above 512 Bytes the block size matters very little (and above 4k, not
| at all).
|
| * Reading line by line is significantly slower than reading by blocks.
> To slurp, I simply undef $/ and
> everything seems fine...
I haven't benchmarked $/ = undef but based on the results above I would
expect it to be as fast as sysread.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Sat, 18 Feb 2012 13:28:46 -0600
From: Bill M <wpmccormick@just_about_everywhere.com>
Subject: rm .cpan?
Message-Id: <jhou5j$od7$1@dont-email.me>
My production machine has only a small (2G) flash drive and I want to
free up as much space as is possible. What are the implications of
completely removing the complete .cpan dir? If I keep part of it intact,
will it make upgrading any easier?
Thanks!!
------------------------------
Date: Sat, 18 Feb 2012 20:52:06 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: rm .cpan?
Message-Id: <mkf519-g9u2.ln1@anubis.morrow.me.uk>
Quoth Bill M <wpmccormick@just_about_everywhere.com>:
> My production machine has only a small (2G)
(Small? When Oi were a lad all us had were 400K 40-track floppies...)
> flash drive and I want to
> free up as much space as is possible. What are the implications of
> completely removing the complete .cpan dir? If I keep part of it intact,
> will it make upgrading any easier?
You want to keep .cpan/CPAN and .cpan/prefs (unless it's empty), since
they both contain irreplaceable preferences; and if you've generated any
bundles in .cpan/Bundle you need to check if you still want them.
Everything else can go, though of course it will need to be downloaded
again if you need it.
You may also want to look into App::cpanminus, which is much better
about not keeping things for too long. For one thing, it doesn't try to
keep a local copy of the metadata.
Ben
------------------------------
Date: Sat, 18 Feb 2012 15:21:02 -0600
From: Bill M <wpmccormick@just_about_everywhere.com>
Subject: Re: rm .cpan?
Message-Id: <jhp4o2$uhs$1@dont-email.me>
Ben Morrow wrote, On 2/18/2012 2:52 PM:
>
> Quoth Bill M<wpmccormick@just_about_everywhere.com>:
>> My production machine has only a small (2G)
>
> (Small? When Oi were a lad all us had were 400K 40-track floppies...)
>
>> flash drive and I want to
>> free up as much space as is possible. What are the implications of
>> completely removing the complete .cpan dir? If I keep part of it intact,
>> will it make upgrading any easier?
>
> You want to keep .cpan/CPAN and .cpan/prefs (unless it's empty), since
> they both contain irreplaceable preferences; and if you've generated any
> bundles in .cpan/Bundle you need to check if you still want them.
> Everything else can go, though of course it will need to be downloaded
> again if you need it.
>
> You may also want to look into App::cpanminus, which is much better
> about not keeping things for too long. For one thing, it doesn't try to
> keep a local copy of the metadata.
>
> Ben
>
Thanks Ben. You date yourself. Moore's Law has indeed been kind to us,
the early struggles notwithstanding.
Speaking of Bundle, I will eventually want to make a Bundle to speed up
the roll out of production machines (something I've not done before). I
gather I should do this BEFORE I remove anything?
I tried cpanm hoping that it would offer some mechanism to remove
targeted (unwanted) modules. It did not (or didn't work), so I just went
back to cpan.
Thanks!!
------------------------------
Date: Sun, 19 Feb 2012 02:21:04 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: rm .cpan?
Message-Id: <gt2619-5g.ln1@anubis.morrow.me.uk>
Quoth Bill M <wpmccormick@just_about_everywhere.com>:
>
> Speaking of Bundle, I will eventually want to make a Bundle to speed up
> the roll out of production machines (something I've not done before). I
> gather I should do this BEFORE I remove anything?
I've not really used CPAN's autobundle feature. I tend to make an effort
to keep even my private code in CPAN-style distributions with explicit
dependencies: it's a little harder to maintain at first, but enormously
easier to install later.
That said: all a bundle is is module file in a particular format. The
documentation is in perldoc CPAN, under "Bundles" (it's quite a long way
down). If you know which modules you want to install it's trivial to
create one yourself: just write a .pm with the appropriate pod in it,
and install it somewhere in @INC. Probably the best place would be
.cpan/Bundle, which is in @INC for CPAN.pm but not otherwise. Then you
can 'cpan Bundle::Whatever' and it will install all the modules in the
list (bundles are special-cased so their listed modules are always
reinstalled, even if the bundle itself is already installed.)
An alternative, which I find considerably more useful, is pip (from
CPAN). This will install private modules from tarballs as well as
public CPAN modules, and will let you depend on specific versions of
CPAN modules rather than always installing the latest. You do have to do
the work of building the list of modules you need yourself, though. (You
don't have to list *every* module, of course, just the ones your code
needs directly. pip knows how to follow dependencies from there onto
CPAN, even when it's building code that didn't come from there.)
> I tried cpanm hoping that it would offer some mechanism to remove
> targeted (unwanted) modules. It did not (or didn't work), so I just went
> back to cpan.
Uninstalling is not a thing the Perl toolchain currently does at all
well, or indeed at all, much. It's a shame, because I think all the
information's there. You can use ExtUtils::Installed to find the
distribution a module belongs to, and to get a list of the files
installed from that distribution; uninstalling should then simply be a
matter of deleting all those files.
Of course, this will completely ignore any still-installed modules that
still depend on the modules you've just removed; and if the distribution
had replaced anything that came in the core you'll end up with a mess.
If you want to be able to uninstall things cleanly you need a proper
package management system, which CPAN.pm isn't. (For one thing, the
dependancy information doesn't exist after a module's been installed.)
Ben
------------------------------
Date: Fri, 17 Feb 2012 11:57:26 -0800 (PST)
From: happytoday <ehabaziz2001@gmail.com>
Subject: Re: sorting unicode file under windows command line
Message-Id: <55a53580-0b11-4b35-92dd-ed9a5941da1d@9g2000vbq.googlegroups.com>
On Feb 15, 10:13=A0pm, tchr...@perl.com wrote:
> On Tuesday, February 14, 2012 8:34:40 AM UTC-7, Eric Pement wrote:
> > A comment on stackoverflow.com says this:
>
> > ... keep in mind that GNU sort depends on a correct locale setting
> > (the LC_* environment variables, and specifically the LC_COLLATE one).
> > LC_COLLATE (or LC_ALL) should be set to a locale with UTF-8 support
> > (e.g. en_US.UTF-8 or el_GR.UTF-8), preferably in the language that you
> > are interested in.
>
> This is the problem with all the vendor-locale things: they are unreliabl=
e,
> and they require particular locale settings. =A0This is not reasonable in
> a Unicode world. =A0Much better to use Unicode::Collate and if necessary =
also
> Unicode::Collate::Locale. =A0For example, a pure-Perl solution for sortin=
g
> according to =A0German phonebook conventions, and with uppercase
> before lowercase, is:
>
> =A0 =A0 $ ucsort --locale=3Dde__phonebook --upper_before_lower
Firstly about the suggested program suggested by George :
I run :
C:\COMPILER\Perl\bin>perl -e sorting.pl sorting.txt
But also nothing is happened .
About the ucsort : How can I run it under windows environment . The
script is written for unix .
------------------------------
Date: Fri, 17 Feb 2012 12:21:42 -0800
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: sorting unicode file under windows command line
Message-Id: <170220121221425775%jimsgibson@gmail.com>
In article
<55a53580-0b11-4b35-92dd-ed9a5941da1d@9g2000vbq.googlegroups.com>,
happytoday <ehabaziz2001@gmail.com> wrote:
> Firstly about the suggested program suggested by George :
> I run :
> C:\COMPILER\Perl\bin>perl -e sorting.pl sorting.txt
>
> But also nothing is happened .
Why are you using the '-e' option? That is for executing Perl programs
that are entered on the command line. You should use:
perl sorting.pl sorting.txt
See 'perldoc perlrun'
--
Jim Gibson
------------------------------
Date: Fri, 17 Feb 2012 18:50:50 -0800
From: "John W. Krahn" <jwkrahn@example.com>
Subject: Re: Using loop labels and iterating.
Message-Id: <emE%q.2025$L12.1649@newsfe23.iad>
Nene wrote:
> Hi,
>
> This is a script that opens up a log file and searches for the word
> 'started' and if it finds the word, it prints it and iterates to the
> next log file. But for the servers that didn't start, I want it to
> print "didn't start". Please help, thanks.
>
>
>
> #!/usr/bin/perl
> use diagnostics;
> use warnings;
>
> open(SCRATCHPAD,"LOG.txt") or die "can't open $!";
> my @uniq =<SCRATCHPAD>;
>
> NODE:
> foreach my $stuff ( @uniq ) {
> chomp($stuff);
>
> open(STARTUP, "/c\$/$stuff/esp.log") or "die can't open $!";
> my @log_file =<STARTUP>;
>
> LINE:
> for my $line ( @log_file ) {
>
> next LINE if $line !~ /ESP server (started)./;
> my $capture = "$1\n";
> print "$stuff => $capture";
>
> close(STARTUP);
> close(SCRATCHPAD);
>
> }
> }
This may work better (UNTESTED):
#!/usr/bin/perl
use warnings;
use strict;
open my $SCRATCHPAD, '<', 'LOG.txt' or die "can't open 'LOG.txt'
because: $!";
NODE:
while ( my $stuff = <$SCRATCHPAD> ) {
chomp $stuff;
open my $STARTUP, '<', "/c\$/$stuff/esp.log" or die "can't open
'/c\$/$stuff/esp.log' because: $!";
while ( my $line = <$STARTUP> ) {
if ( $line =~ /ESP server started\./ ) {
print "$stuff => started";
next NODE;
}
}
print "$stuff => didn't start";
}
__END__
John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
------------------------------
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 3614
***************************************
