[29522] in Perl-Users-Digest
Perl-Users Digest, Issue: 766 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 17 16:09:44 2007
Date: Fri, 17 Aug 2007 13:09:06 -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 Fri, 17 Aug 2007 Volume: 11 Number: 766
Today's topics:
Re: about CGI <attackack@yahoo.com>
Re: FAQ 6.16 How do I efficiently match many regular ex <allergic-to-spam@no-spam-allowed.org>
Help on compiling Perl 5.8.8 <sigzero@gmail.com>
Re: How to get "<$myclass_instance>" to work? <socyl@987jk.com.invalid>
Re: How to get "<$myclass_instance>" to work? <uri@stemsystems.com>
Re: Perl Help <1usa@llenroc.ude.invalid>
Perl Search Help mihirtr@gmail.com
Re: Perl Search Help <glex_no-spam@qwest-spam-no.invalid>
Re: Perl Search Help (Jens Thoms Toerring)
Re: Rename Perl Process <wogri.wogri@gmail.com>
Re: Using Subroutines with CGI::Session::MySQL? xhoster@gmail.com
Re: Using Subroutines with CGI::Session::MySQL? xhoster@gmail.com
Re: Using Subroutines with CGI::Session::MySQL? <ljames@apollo3.com>
Re: Using Subroutines with CGI::Session::MySQL? <ljames@apollo3.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 17 Aug 2007 08:38:27 -0700
From: joker <attackack@yahoo.com>
Subject: Re: about CGI
Message-Id: <1187365107.002788.166250@a39g2000hsc.googlegroups.com>
Thanks a lot to all.
A word to Bryan
Really my english is so important?? The others guys has answered me
very well. You have to be more flexible about language...You are on
internet, DO YOU KNOW THAT?
------------------------------
Date: Fri, 17 Aug 2007 21:40:06 +0200 (CEST)
From: Jim Cochrane <allergic-to-spam@no-spam-allowed.org>
Subject: Re: FAQ 6.16 How do I efficiently match many regular expressions at once?
Message-Id: <slrnfcbucl.rj6.allergic-to-spam@no-spam-allowed.org>
On 2007-08-16, Michele Dondi <bik.mido@tiscalinet.it> wrote:
> On Tue, 14 Aug 2007 21:31:09 +0200 (CEST), Jim Cochrane
><allergic-to-spam@no-spam-allowed.org> wrote:
>
>>> @patterns = map { qr/\b$_\b/i } qw( foo bar baz );
>>>
>>> LINE: while( <> )
>>> {
>>> foreach $pattern ( @patterns )
>>> {
>>> print if /\b$pattern\b/i;
>>
>># Aren't the '\b's redundant here, or am I missing something? If so,
>># does this slow processing down slightly?
>
> Yep, I guess that an original version of the entry didn't have the
> map(), then it was added, and \b's were forgotten in the match.
>
>
> Michele
Yes, I thought it was something like that. Too bad there are no
lint-like tools to help keep documentation consistent. [English is a
language - shouldn't we be able to compile it? :=)]
--
------------------------------
Date: Fri, 17 Aug 2007 12:04:22 -0700
From: Robert Hicks <sigzero@gmail.com>
Subject: Help on compiling Perl 5.8.8
Message-Id: <1187377462.759466.281780@d55g2000hsg.googlegroups.com>
We rebuilt a Linux (x86_64) server and during the attempt to make I
get:
/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/
include/gdbm -O2 -Wall
cc -L/usr/local/lib -o miniperl \
miniperlmain.o opmini.o libperl.a /usr/lib/libcrypt.a
libperl.a(pp.o)(.text+0x272c): In function `Perl_pp_pow':
: undefined reference to `pow'
libperl.a(pp.o)(.text+0x346d): In function `Perl_pp_modulo':
: undefined reference to `floor'
libperl.a(pp.o)(.text+0x3495): In function `Perl_pp_modulo':
: undefined reference to `floor'
libperl.a(pp.o)(.text+0x355b): In function `Perl_pp_modulo':
: undefined reference to `fmod'
libperl.a(pp.o)(.text+0x7ce3): In function `Perl_pp_atan2':
: undefined reference to `atan2'
libperl.a(pp.o)(.text+0x7dc3): In function `Perl_pp_sin':
: undefined reference to `sin'
libperl.a(pp.o)(.text+0x7ee3): In function `Perl_pp_cos':
: undefined reference to `cos'
libperl.a(pp.o)(.text+0x8253): In function `Perl_pp_exp':
: undefined reference to `exp'
libperl.a(pp.o)(.text+0x83a5): In function `Perl_pp_log':
: undefined reference to `log'
libperl.a(pp.o)(.text+0x8577): In function `Perl_pp_sqrt':
: undefined reference to `sqrt'
libperl.a(pp.o)(.text+0x8728): In function `Perl_pp_int':
: undefined reference to `ceil'
libperl.a(pp.o)(.text+0x873e): In function `Perl_pp_int':
: undefined reference to `floor'
libperl.a(pp_pack.o)(.text+0x444c): In function `S_pack_rec':
: undefined reference to `floor'
libperl.a(pp_pack.o)(.text+0x4470): In function `S_pack_rec':
: undefined reference to `floor'
collect2: ld returned 1 exit status
make: *** [miniperl] Error 1
[rhicks@sartrain perl-5.8.8]$
We did not get that after we first built the server last week (we are
demoing).
Robert
------------------------------
Date: Fri, 17 Aug 2007 16:04:15 +0000 (UTC)
From: kj <socyl@987jk.com.invalid>
Subject: Re: How to get "<$myclass_instance>" to work?
Message-Id: <fa4gtu$gqn$1@reader1.panix.com>
In <20070817104556.410$5y@newsreader.com> xhoster@gmail.com writes:
>But I agree the other poster who suggested
>while (defined ($_=$myclass_instance->next())) {
>It is uglier than "while (<$mycalss_instance>)", especially the need
>to include the define and extra parentheses, but it is less likely
>to mislead the code reader into thinking it is a real file handle.
The motivation here is not aesthetics, but rather polymorphism.
I want to be able to pass myclass instances to external methods/functions
that expect read handles.
kj
--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.
------------------------------
Date: Fri, 17 Aug 2007 16:55:41 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: How to get "<$myclass_instance>" to work?
Message-Id: <x7ir7eaynm.fsf@mail.sysarch.com>
>>>>> "k" == kj <socyl@987jk.com.invalid> writes:
k> In <x7zm0ri5hu.fsf@mail.sysarch.com> Uri Guttman <uri@stemsystems.com> writes:
>> that i didn't see. but as i think it is less work, tying should be on
>> the table. maybe he was scared by what he thought it needed.
k> No, actually, it's not the amount of work that scares, but rather
k> the fact that I've never gotten the hang of tied variables. For
k> me programming with them is always an exercise in trial and error;
k> I never quite know what to expect. Too much magic for my little
k> brain, I guess.
then you shouldn't be a programmer. in fact programming should never be
trial and error as it is specifically meant to be deterministic by its
very nature. :)
having read overload.pm and seen it in use it is the same level of
complexity as tying but it does it from an operator point of view vs a
variable view. in many ways they are very similar. they both require
objects. i think overloading is more complex because you usually have to
deal with 2 possible operands and how they relate based on the
operator. with <> you only have 1 operand so it simplifies things a bit.
k> But I will study File::ReadBackwards. Thanks for the pointer.
and as i said, i didn't write one special line of code for tying as
such. the OO interface is just aliased to the required tied method
names. that is why tying is simpler IMO than overloading.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Fri, 17 Aug 2007 16:47:33 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Perl Help
Message-Id: <Xns998F822E2A2C2asu1cornelledu@127.0.0.1>
mihirtr@gmail.com wrote in news:1187359719.456172.61500
@m37g2000prh.googlegroups.com:
> I have trying see if it is possible using perl to do following.
Yes.
...
> After running this script, I want get "sizeof( STRUCT_1_T )" ,
> "sizeof(STRUCT_2_T )" as outputs.
What have you tried so far?
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Fri, 17 Aug 2007 09:32:24 -0700
From: mihirtr@gmail.com
Subject: Perl Search Help
Message-Id: <1187368344.018812.168010@e9g2000prf.googlegroups.com>
Hi,
I am trying to do following with Perl. Can someone check and help me
out if it is possible.
I am have multiple .c files, I need to find out second parameter in
function call My_Function_Test from these files and output to a file.
For example:
Example .c file
Sample_Func1()
{
MY_STRUCT_1 abc;
My_Function_Test (MY_1ST_PARAMETER,
sizeof(MY_STRUCT_1),
MY_3RD_PARAMETER);
}
Sample_Func1()
{
MY_STRUCT_2 abc;
My_Function_Test (MY_1ST_PARAMETER,
sizeof(MY_STRUCT_2),
MY_3RD_PARAMETER);
}
After running perl script, the output should be following
sizeof(MY_STRUCT_1)
sizeof(MY_STRUCT_2)
------------------------------
Date: Fri, 17 Aug 2007 11:36:59 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Perl Search Help
Message-Id: <46c5ceab$0$490$815e3792@news.qwest.net>
mihirtr@gmail.com wrote:
> Hi,
> I am trying to do following with Perl. Can someone check and help me
> out if it is possible.
>
> I am have multiple .c files, I need to find out second parameter in
> function call My_Function_Test from these files and output to a file.
Post what you have tried so far.
------------------------------
Date: 17 Aug 2007 17:09:41 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: Perl Search Help
Message-Id: <5im32lF3ppr84U1@mid.uni-berlin.de>
mihirtr@gmail.com wrote:
> I am trying to do following with Perl. Can someone check and help me
> out if it is possible.
> I am have multiple .c files, I need to find out second parameter in
> function call My_Function_Test from these files and output to a file.
> For example:
> Example .c file
> Sample_Func1()
> {
> MY_STRUCT_1 abc;
> My_Function_Test (MY_1ST_PARAMETER,
> sizeof(MY_STRUCT_1),
> MY_3RD_PARAMETER);
> }
> Sample_Func1()
> {
> MY_STRUCT_2 abc;
> My_Function_Test (MY_1ST_PARAMETER,
> sizeof(MY_STRUCT_2),
> MY_3RD_PARAMETER);
> }
> After running perl script, the output should be following
> sizeof(MY_STRUCT_1)
> sizeof(MY_STRUCT_2)
If you don't mind a few false positives (from the functions
definition and possible prototype declarations or places where
calls of the function are commented out) and and the way you
call the function isn't too complicated (e.g. with arguments
that are enclosed in parenthesis and then contain commas or
the functions, the function call isn't part of a macro etc.)
it can be rather simple: Read in the whole file into a single
string and do repeated regexp searches for
\WMy_Function_Test\s*\([^,]*,\s*([^,]*)
The second argument should then be in $1. Print it out after
removing trailing white space. But for a 100% reliable solu-
tion I guess you probably will need a full-blown preprocessor
and parser for C.
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
Date: Fri, 17 Aug 2007 11:26:30 -0700
From: Wolfgang Hennerbichler <wogri.wogri@gmail.com>
Subject: Re: Rename Perl Process
Message-Id: <1187375190.441940.67280@r29g2000hsg.googlegroups.com>
On Aug 17, 4:34 pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> And those error messages also will never appear anywhere since
> neither STDOUT nor STDERR are open anymore.
Well, I didn't really show you how my real program looks like. There's
also this section:
141 if (defined ($options{l}) and not defined $options{d}) {
142 open (STDERR, ">>$options{l}");
143 STDERR->autoflush(1);
144 }
that recreates the STDERR filehandle and sends it to the destination
of the logfile. So don't worry, my error messages are in a safe
place :)
> BTW, it looks a bit as if you want to create a daemon, and
> the usual way to create one is forking twice (always letting
> the parent process exit).
Why? You might be right, but I don't know the reason for the double-
fork, it works perfectly with the single-fork here.
> It's can't be done via fork() which just (nearly) duplicates your
> process. But what you can try is to assign a new value to $0 before
> you fork(). I don't think it's guaranteed to work on all UNIX systems
> but it seems to work on Linux.
It's a linux-only program (it is actually a daemon that collects sflow
data on an internet exchange and it's gotten so important (and big) by
now that I need to identify the different daemons that are dealing
with the sflow data).
thanks folks.
wogri
------------------------------
Date: 17 Aug 2007 15:17:09 GMT
From: xhoster@gmail.com
Subject: Re: Using Subroutines with CGI::Session::MySQL?
Message-Id: <20070817111712.731$9g@newsreader.com>
"L. D. James" <ljames@apollo3.com> wrote:
> On Aug 17, 12:14 am, "Mumia W." <paduille.4061.mumia.w
> +nos...@earthlink.net> wrote:
>
> > Mod_perl is a strange environment. It's built for breath-taking
> > efficiency, but it complicates programming. This wasn't a Perl leak--it
> > was an effect of the additional complexity brought by mod_perl.
>
> I really don't think I'm running mod_perl. I asked a few times how
> can I verify weather I am or not.
The *best* way is to figure out how to read your apache configuration,
or ask someone who already does know. You can also print our the
%ENV hash and see what it looks like.
## after printing the cgi/session header:
use Data::Dumper;
print pre(Dumper \%ENV);
On my machine, when running on mod_perl, I get a variable
'MOD_PERL' => 'mod_perl/1.99_09'
and it isn't there when doing straight CGI.
> I would think that I'm running the
> regular perl since the first line of each one of my scripts have, "#!/
> usr/local/bin/perl", at the top.
That doesn't make any difference. If the process already knows that it is
perl, then the program specified on that line will not matter. (For
example, you can do "/usr/local/bin/perl foo.pl" and it will use
/usr/local/bin/perl, even if the #! line of foo.pl says something else, or
nothing at all.
> If mod_perl insist on running in spite of this declaration, then I
> don't know.
That would be better phrased "If I insist on configuring my apache to use
mod_perl in spite of that declaration...." (which is the normal
configuration. I've never heard of one in which apache inspects #! in
order to decide whether to use mod_perl)
mod_perl is not a sentient being. You are.
Cheers,
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 17 Aug 2007 15:29:54 GMT
From: xhoster@gmail.com
Subject: Re: Using Subroutines with CGI::Session::MySQL?
Message-Id: <20070817112958.108$OS@newsreader.com>
"L. D. James" <ljames@apollo3.com> wrote:
> On Aug 16, 9:18 pm, xhos...@gmail.com wrote:
>
> > Are you sure you are looking in the right place?
> > I'd add something like this, which certainly should
> > produce warnings, to your code:
> >
> > sub sdfsadf { my $x; sub alkj { $x }};
> >
> > Should produce warnings like
> > Variable "$x" will not stay shared at -e line 1.
> >
> > If you don't see messages corresponding to that, then you may
> > be looking in the wrong place. On your original code, I found
> > these warnings on $session, $name, and $count.
>
> Yes. I get the error you mention when adding your line to the sample
> code. But my example didn't produce errors before adding the lines.
> Studying your reference to my example giving errors on your machine, I
> was able to duplicate and figure out why I wasn't getting errors.
> This is because there is information in the variables since having ran
> the code, so I wasn't getting the uninitialized error message with
> $name and $count.
The uninitialized message is different from the "will not stayed shared"
message. One happens at run time, one at compile time.
> A fresh load of the code from a different machine that didn't have the
> any of the cookie information would initially give the warnings. I
> fixed the warnings by initializing them with a default null value as:
>
> $name = $session->param('f_name') || "";
> $count = $session->param("count") || "0";;
It is the occurence of $name and $count (and $session) inside the sub
that gives rise to the will not stay shared errors. The references
outside the sub are not relevant to that matter.
...
>
> I had mentioned in my description that there was no problem accessing
> the session information. The problem was in writing, or updating the
> session information.
Are you sure? On my system, running your code, the information was being
updated just fine. It didn't *look* like it was being updated, because
the information retrieved and printed did not reflect the update. That
isn't because it wasn't being updated, but rather because it was being
retrieved from the wrong session.
If I report $count both inside the sub and in the main code, I noticed
that the one printed from the main code always appeared to be updated,
while the one printed from the sub appeared not to be.
> I'm not sure if my code on my machine is operating under any version
> of mod_perl. Do you get this same effect if you include a specifier
> in the first line of the script, "#!/usr/local/bin/perl" or wherever
> your normal perl is installed?
mod_perl doesn't care about your #! line.
> > Those sources make very scant reference to mod_perl. If you are going
> > to run under mod_perl, you definitely need to read up on that, as well.
> > The problems you are seeing are due to way you are using mod_perl, and
> > related problems may well pop up in contexts other than CGI::Session as
> > well. Generally I just avoid mod_perl until I know for certain that
> > it is necessary.
>
> Likewise, I have not intentionally used mod_perl and don't think I
> am. Can you tell me how to insure that I am avoiding mod_perl, as you
> do?
Sorry, I'm just barely competent (if that) to configure my own apache
installation, and am in no position to help other people with theirs.
After all, I'm a Perl person, not an apache person. You might want
to seek help in an apache-specific resource.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Fri, 17 Aug 2007 11:51:28 -0700
From: "L. D. James" <ljames@apollo3.com>
Subject: Re: Using Subroutines with CGI::Session::MySQL?
Message-Id: <1187376688.948178.84590@o80g2000hse.googlegroups.com>
On Aug 17, 11:17 am, xhos...@gmail.com wrote:
> The *best* way is to figure out how to read your apache configuration,
> or ask someone who already does know. You can also print our the
> %ENV hash and see what it looks like.
>
> ## after printing the cgi/session header:
> use Data::Dumper;
> print pre(Dumper \%ENV);
Checking the environment hash, mod_perl isn't in the picture in my
programs and scripts.
>
> On my machine, when running on mod_perl, I get a variable
> 'MOD_PERL' => 'mod_perl/1.99_09'
> and it isn't there when doing straight CGI.
>
> > I would think that I'm running the
> > regular perl since the first line of each one of my scripts have, "#!/
> > usr/local/bin/perl", at the top.
>
> That doesn't make any difference. If the process already knows that it is
> perl, then the program specified on that line will not matter. (For
> example, you can do "/usr/local/bin/perl foo.pl" and it will use
> /usr/local/bin/perl, even if the #! line of foo.pl says something else, or
> nothing at all.
Thanks for the information on this.
> > If mod_perl insist on running in spite of this declaration, then I
> > don't know.
>
> That would be better phrased "If I insist on configuring my apache to use
> mod_perl in spite of that declaration...." (which is the normal
> configuration. I've never heard of one in which apache inspects #! in
> order to decide whether to use mod_perl)
Since it doesn't inspect the configuration, it will (insist/ persist
to) use mod_perl or whatever it chooses to use based on other elements
(of which are currently beyond my immediate knowledge, though I'm
learning fast).
> mod_perl is not a sentient being. You are.
Of course it isn't. There are times when people describe insentient
elements such as storms, automobiles, ships, computers, etc... as if
they where doing something. When someone says, the computer did... I
realize they really mean the computer programmer or operator did...
-- L. James
--
L. D. James
ljames@apollo3.com
www.apollo3.com/~ljames
------------------------------
Date: Fri, 17 Aug 2007 12:22:29 -0700
From: "L. D. James" <ljames@apollo3.com>
Subject: Re: Using Subroutines with CGI::Session::MySQL?
Message-Id: <1187378549.025257.24440@d55g2000hsg.googlegroups.com>
On Aug 17, 11:29 am, xhos...@gmail.com wrote:
> "L. D. James" <lja...@apollo3.com> wrote:
> > On Aug 16, 9:18 pm, xhos...@gmail.com wrote:
> The uninitialized message is different from the "will not stayed shared"
> message. One happens at run time, one at compile time.
>
> > A fresh load of the code from a different machine that didn't have the
> > any of the cookie information would initially give the warnings. I
> > fixed the warnings by initializing them with a default null value as:
>
> > $name = $session->param('f_name') || "";
> > $count = $session->param("count") || "0";;
>
> It is the occurence of $name and $count (and $session) inside the sub
> that gives rise to the will not stay shared errors. The references
> outside the sub are not relevant to that matter.
After studying the results environment hash, I'm sure this explains
why you and I see some things differently. You mentioned that
mod_perl behave different from straight perl. I don't run mod_perl.
> > I had mentioned in my description that there was no problem accessing
> > the session information. The problem was in writing, or updating the
> > session information.
>
> Are you sure? On my system, running your code, the information was being
> updated just fine. It didn't *look* like it was being updated, because
> the information retrieved and printed did not reflect the update. That
> isn't because it wasn't being updated, but rather because it was being
> retrieved from the wrong session.
>
> If I report $count both inside the sub and in the main code, I noticed
> that the one printed from the main code always appeared to be updated,
> while the one printed from the sub appeared not to be.
On mine, it would be updated, subsequently upon calling the data, it
would read the data, and display what had been placed in the cookie
session. The display of the data would function equally whether being
called from the sub routine or from the main program. When it appears
in the variable would depend on when it was placed in the session and
read from the session.
Again, session reads are never a problem on my system, only updating
the session.
> > Likewise, I have not intentionally used mod_perl and don't think I
> > am. Can you tell me how to insure that I am avoiding mod_perl, as you
> > do?
>
> Sorry, I'm just barely competent (if that) to configure my own apache
> installation, and am in no position to help other people with theirs.
Without trying, you inadvertently showed me by way of the environment
hash code you mentioned in the previous message.
> After all, I'm a Perl person, not an apache person. You might want
> to seek help in an apache-specific resource.
I didn't know that mod_perl was in the picture. I had intentionally
tried to leave it out. It seems as if I actually succeeded. I'm very
concerned about the consistent behavior of my programs, that's why I
put so much into knowing as much about the environment as I can.
That's why I endeavored to use straight perl, of which I hoped had
some consistency with the reference manuals I was studying.
-- L. James
--
L. D. James
ljames@apollo3.com
www.apollo3.com/~ljames
------------------------------
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 766
**************************************
