[31543] in Perl-Users-Digest
Perl-Users Digest, Issue: 2802 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 3 14:09:32 2010
Date: Wed, 3 Feb 2010 11:09:14 -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 Wed, 3 Feb 2010 Volume: 11 Number: 2802
Today's topics:
Re: function within qq{} <john@castleamber.com>
Re: function within qq{} <whynot@pozharski.name>
Re: function within qq{} <marc.girod@gmail.com>
Re: function within qq{} <marc.girod@gmail.com>
Re: function within qq{} <nospampleasebutthisisvalid3@gmx.net>
Re: function within qq{} <uri@StemSystems.com>
Re: function within qq{} <marc.girod@gmail.com>
Re: function within qq{} <john@castleamber.com>
Perl: Read French <anderswang@gmail.com>
Re: Perl: Read French <jurgenex@hotmail.com>
Re: Perl: Read French <anderswang@gmail.com>
Re: Perl: Read French <hhr-m@web.de>
Re: Perl: Read French <jimsgibson@gmail.com>
Re: Perl: Read French <jurgenex@hotmail.com>
Python's Reference And Internal Model Of Computing Lang <xahlee@gmail.com>
Re: Want your opinion on @ARGV file globbing <xhoster@gmail.com>
Re: Want your opinion on @ARGV file globbing <xhoster@gmail.com>
Re: Want your opinion on @ARGV file globbing <jurgenex@hotmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 02 Feb 2010 22:44:30 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: function within qq{}
Message-Id: <87k4uvrkr5.fsf@castleamber.com>
"Uri Guttman" <uri@StemSystems.com> writes:
>>>>>> "JB" == John Bokma <john@castleamber.com> writes:
>
> JB> cate <catebekensail@yahoo.com> writes:
> >> I know you can do this, I just can't find it.
> >> How do you call a sub within a qq{} construct
> >>
> >> qq{The common term for H2O is chem("H2O").}
> >>
> >> Thank you
> >>
> >> (As soon is this post is complete... I'll find it) :-)
>
> JB> perl -e '
> JB> sub chem {
> JB> my $term = shift;
> JB> return "*$term*";
> JB> }
> JB> print qq{The common term for H2O is ${\( chem("H2O") ) }};
> JB> '
>
> JB> use @{...} for list expressions, ${...} for scalar.
>
> partly incorrect.
I stand corrected, thanks (Ben too). I haven't used this construct for
ages, don't really like it.
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
------------------------------
Date: Wed, 03 Feb 2010 10:18:12 +0200
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: function within qq{}
Message-Id: <slrnhmica5.i36.whynot@orphan.zombinet>
with <87pr4n8qbu.fsf@quad.sysarch.com> Uri Guttman wrote:
*SKIP*
> yes, but the "${\foo()}" idiom looks like it will be in scalar
> context. that is the issue. you need to put a scalar() in there. whether
> it is a true bug or not, i say this is one reason to not use this
> trick. using a variable is simpler, probably faster and safer.
s/probably/definetely/
#!/usr/bin/perl
use strict;
use warnings;
use Benchmark qw{ cmpthese timethese };
sub abc {
return "abc";
}
sub def {
my $t = "def";
return "*$t";
}
my( $x, $y );
cmpthese timethese -5, {
code00 => sub { $x = "@{[ abc ]}"; },
code01 => sub { $x = "${\( def )}"; },
code02 => sub { $y = abc; $x = "$y"; },
};
__END__
Benchmark: running code00, code01, code02 for at least 5 CPU seconds...
code00: 6 wallclock secs ( 5.17 usr + 0.00 sys = 5.17 CPU) @ 559916.63/s (n=2894769)
code01: 7 wallclock secs ( 5.09 usr + 0.00 sys = 5.09 CPU) @ 667528.49/s (n=3397720)
code02: 7 wallclock secs ( 5.27 usr + 0.00 sys = 5.27 CPU) @ 941641.56/s (n=4962451)
Rate code00 code01 code02
code00 559917/s -- -16% -41%
code01 667528/s 19% -- -29%
code02 941642/s 68% 41% --
p.s. "faster" is strawman, anyway
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Wed, 3 Feb 2010 05:45:55 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: function within qq{}
Message-Id: <77ae494c-e211-4db5-9117-79db8982cc3d@v25g2000yqk.googlegroups.com>
On Feb 2, 4:50=A0pm, John Bokma <j...@castleamber.com> wrote:
> sub chem {
> =A0 =A0 my $term =3D shift;
> =A0 =A0 return "*$term*";}
I think the common name for H2O is 'water'.
Marc
------------------------------
Date: Wed, 3 Feb 2010 05:54:06 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: function within qq{}
Message-Id: <ea8a3542-9f60-471c-89d6-a2761889c7fb@f12g2000yqn.googlegroups.com>
On Feb 2, 10:19=A0pm, "Uri Guttman" <u...@StemSystems.com> wrote:
> and what is wrong with my suggestio of a simple variable assignment
> before the string is built? that is all the OP needs.
It requires a block around it when used with 'for'?
I.e. one might consider it as needless verbosity, in a context where
compacity would enhance readability...
print qq{The common term for $_ is ${ \chem($_) }} for @molecule;
Suppose you have 10 such lines...
Marc
------------------------------
Date: Wed, 03 Feb 2010 15:07:25 +0100
From: Wolf Behrenhoff <nospampleasebutthisisvalid3@gmx.net>
Subject: Re: function within qq{}
Message-Id: <4b69831e$0$6721$9b4e6d93@newsspool2.arcor-online.net>
Marc Girod wrote:
> On Feb 2, 10:19 pm, "Uri Guttman" <u...@StemSystems.com> wrote:
>
>> and what is wrong with my suggestio of a simple variable assignment
>> before the string is built? that is all the OP needs.
>
> It requires a block around it when used with 'for'?
> I.e. one might consider it as needless verbosity, in a context where
> compacity would enhance readability...
>
> print qq{The common term for $_ is ${ \chem($_) }} for @molecule;
>
> Suppose you have 10 such lines...
Use printf.
printf "The common term for %s is %s\n", $_, chem($_) for @molecule;
I never do a function call in a qq string because I consider that bad style.
- Wolf
------------------------------
Date: Wed, 03 Feb 2010 10:17:17 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: function within qq{}
Message-Id: <87zl3quz5u.fsf@quad.sysarch.com>
>>>>> "WB" == Wolf Behrenhoff <nospampleasebutthisisvalid3@gmx.net> writes:
WB> Marc Girod wrote:
>> On Feb 2, 10:19 pm, "Uri Guttman" <u...@StemSystems.com> wrote:
>>
>>> and what is wrong with my suggestio of a simple variable assignment
>>> before the string is built? that is all the OP needs.
>>
>> It requires a block around it when used with 'for'?
>> I.e. one might consider it as needless verbosity, in a context where
>> compacity would enhance readability...
>>
>> print qq{The common term for $_ is ${ \chem($_) }} for @molecule;
>>
>> Suppose you have 10 such lines...
WB> Use printf.
and that was mentioned by ben iirc. i would use sprintf instead as my
rule is print rarely, print late. i can't recall ever using printf
directly, whereas i use sprintf when i need too.
WB> I never do a function call in a qq string because I consider that
WB> bad style.
and we have another true believer! :)
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Wed, 3 Feb 2010 07:18:47 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: function within qq{}
Message-Id: <ed562a0c-8ee2-4a5f-9a34-9d307dfdcc64@v25g2000yqk.googlegroups.com>
On Feb 3, 2:07=A0pm, Wolf Behrenhoff
<nospampleasebutthisisval...@gmx.net> wrote:
> Use printf.
This was Ben's answer, and... I agree, at least in that case
(and I cannot make another one now).
But I was replying to Uri's challenge.
Marc
------------------------------
Date: Wed, 03 Feb 2010 11:16:24 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: function within qq{}
Message-Id: <87tytyfdef.fsf@castleamber.com>
Marc Girod <marc.girod@gmail.com> writes:
> On Feb 2, 4:50Â pm, John Bokma <j...@castleamber.com> wrote:
>
>> sub chem {
>> Â Â my $term = shift;
>> Â Â return "*$term*";}
>
> I think the common name for H2O is 'water'.
LMAO!
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
------------------------------
Date: Wed, 3 Feb 2010 08:13:07 -0800 (PST)
From: micropentium <anderswang@gmail.com>
Subject: Perl: Read French
Message-Id: <971497e2-198f-4fa9-9599-cc363bf2ae11@n7g2000yqb.googlegroups.com>
Hi,
I have a perl script that needs to read plain text from database that
may contain French. My script failed to interpret French characters
but those French characters look OK in the database.
My question is: How does Perl handle the unicode?
Many thanks
------------------------------
Date: Wed, 03 Feb 2010 08:22:20 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl: Read French
Message-Id: <ea8jm5pfgdu47phs60kspi6o94grso1p3u@4ax.com>
micropentium <anderswang@gmail.com> wrote:
>I have a perl script that needs to read plain text from database that
>may contain French. My script failed to interpret French characters
>but those French characters look OK in the database.
>
>My question is: How does Perl handle the unicode?
Just fine, no problems.
Maybe that database is not in Unicode but in some other character set?
Have you tried ISO-8859-1 or -15 or Windopws-1252?
Those are the most likely candidates but there are others, too.
Or maybe your are simply using the wrong encoding, e.g. UTF-16 when the
database returns UTF-8?
jue
------------------------------
Date: Wed, 3 Feb 2010 08:44:54 -0800 (PST)
From: micropentium <anderswang@gmail.com>
Subject: Re: Perl: Read French
Message-Id: <01893b58-af05-4334-8209-7bd0e48b64a2@q16g2000yqq.googlegroups.com>
On Feb 3, 11:22 am, J=FCrgen Exner <jurge...@hotmail.com> wrote:
> micropentium <andersw...@gmail.com> wrote:
> >I have a perl script that needs to read plain text from database that
> >may contain French. My script failed to interpret French characters
> >but those French characters look OK in the database.
>
> >My question is: How does Perl handle the unicode?
>
> Just fine, no problems.
>
> Maybe that database is not in Unicode but in some other character set?
> Have you tried ISO-8859-1 or -15 or Windopws-1252?
> Those are the most likely candidates but there are others, too.
>
> Or maybe your are simply using the wrong encoding, e.g. UTF-16 when the
> database returns UTF-8?
>
> jue
Hi JE,
I am actually a newbie to Perl and not familiar with Perl's unicde
processing. Would you mind to provide a small piece of codes on
unicode handling? So I can take them as the start point.
Cordially,
------------------------------
Date: Wed, 3 Feb 2010 18:19:45 +0100
From: Helmut Richter <hhr-m@web.de>
Subject: Re: Perl: Read French
Message-Id: <Pine.LNX.4.64.1002031806260.4430@lxhri01.lrz.lrz-muenchen.de>
On Wed, 3 Feb 2010, micropentium wrote:
> On Feb 3, 11:22 am, Jürgen Exner <jurge...@hotmail.com> wrote:
> > Just fine, no problems.
That's exaggerated.
It is the user who has to keep track which of his strings are meant as
bytes and which are meant as text characters. The details are explained
in http://perldoc.perl.org/perlunitut.html .
Problems may arise when subroutines of unknown modules are used and it is not
specified which kind of strings are expected.
> > Maybe that database is not in Unicode but in some other character set?
> > Have you tried ISO-8859-1 or -15 or Windopws-1252?
> > Those are the most likely candidates but there are others, too.
This should be seriously considered as a possible source of problems.
The code used in the data must be known; it cannot be inferred from the
contents read.
(That's the theory. In practice, it is highly improbable that a string of
bytes is meant as anything other the UTF-8 if it is a correct UTF-8 string.)
> I am actually a newbie to Perl and not familiar with Perl's unicde
> processing. Would you mind to provide a small piece of codes on
> unicode handling? So I can take them as the start point.
You should start with thoroughly understanding the tutorial cited above and
then understand other people's code.
--
Helmut Richter
------------------------------
Date: Wed, 03 Feb 2010 09:43:17 -0800
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: Perl: Read French
Message-Id: <030220100943179673%jimsgibson@gmail.com>
In article
<01893b58-af05-4334-8209-7bd0e48b64a2@q16g2000yqq.googlegroups.com>,
micropentium <anderswang@gmail.com> wrote:
>
> I am actually a newbie to Perl and not familiar with Perl's unicde
> processing. Would you mind to provide a small piece of codes on
> unicode handling? So I can take them as the start point.
Check out the documentation that comes with Perl:
perldoc perlunicode
--
Jim Gibson
------------------------------
Date: Wed, 03 Feb 2010 09:56:52 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Perl: Read French
Message-Id: <ttcjm559r6f1h53rvmd8emfusl0su75ju4@4ax.com>
Helmut Richter <hhr-m@web.de> wrote:
>On Wed, 3 Feb 2010, micropentium wrote:
>> On Feb 3, 11:22 am, Jürgen Exner <jurge...@hotmail.com> wrote:
>
>> > Just fine, no problems.
>
>That's exaggerated.
Well, each and every Perl text is in Unicode already. So there really
_is_ no problem. The problems appear when you start mugging around and
interfacing with other character sets and encodings, Then you really
need to keep track of if you have (Perl) text (in Unicode) or some
binary data in some other format and when and how to convert between
those. Not to mention to use the right encoding settings when reading
from such files as was discussed very recently here.
On the plus side there are some really great conversion tools and years
ago it was Perl that helped me to save a very large software product by
being able to automatically convert text into numerous local email
encodings.
>It is the user who has to keep track which of his strings are meant as
>bytes and which are meant as text characters. The details are explained
>in http://perldoc.perl.org/perlunitut.html .
Yikes! The term "string" usually implies text, therefore may I rephrase
that as "... has to keep track which of his scalars are meant to contain
binary data (e.g. pictures, hex dumps, file images, yenc-encoded data,
shift-JIS encoded email, ...) and which are meant as text"? This way
you can avoid the awkward "byte string".
>Problems may arise when subroutines of unknown modules are used and it is not
>specified which kind of strings are expected.
It should (emphais being on should) be clear if they expect binary data
or text.
>> I am actually a newbie to Perl and not familiar with Perl's unicde
>> processing. Would you mind to provide a small piece of codes on
>> unicode handling? So I can take them as the start point.
>
>You should start with thoroughly understanding the tutorial cited above and
>then understand other people's code.
Thanks, should have mentioned that myself.
jue
------------------------------
Date: Tue, 2 Feb 2010 17:28:10 -0800 (PST)
From: Xah Lee <xahlee@gmail.com>
Subject: Python's Reference And Internal Model Of Computing Languages
Message-Id: <7ed330b7-8bc2-4eac-be92-615e8b865fd6@z10g2000prh.googlegroups.com>
just wrote this essay. Comment & feedback very welcome.
Python's Reference And Internal Model Of Computing Languages
Xah Lee, 2010-02-02
In Python, there are 2 ways to clear a hash: =E2=80=9CmyHash =3D {}=E2=80=
=9D and
=E2=80=9CmyHash.clear()=E2=80=9D. What is the difference?
=E2=86=93
The difference is that =E2=80=9CmyHash=3D{}=E2=80=9D simply creates a new e=
mpty hash and
assigns to myHash, while =E2=80=9CmyHash.clear()=E2=80=9D actually clear th=
e hash the
myHash is pointing to.
What does that mean?? Here's a code that illustrates:
# python
# 2 ways to clear hash and their difference
aa =3D {'a':3, 'b':4}
bb =3D aa
aa =3D {}
print bb # prints {'a': 3, 'b': 4}
aa =3D {'a':3, 'b':4}
bb =3D aa
aa.clear()
print bb # prints {}
This is like this because of the =E2=80=9Creference=E2=80=9D concept. The o=
pposite
alternative, is that everything is a copy, for example in most
functional langs. (with respect to programer-visible behavior, not how
it is implemented)
From the aspect of the relation of the language source code to the
program behavior by the source code, this =E2=80=9Creference=E2=80=9D-induc=
ed behavior
is similar to dynamic scope vs lexicol scope. The former being un-
intuitive and hard to understand the latter more intuitive and clear.
The former requires the lang to have a internal model of the language,
the latter more correspond to source code WYSIWYG. The former being
easy to implement and is in early langs, the latter being more popular
today.
As with many languages that have concept of references, or pointers,
this is a complexity that hampers programing progress. The concept of
using some sort of =E2=80=9Creference=E2=80=9D as part of the language is d=
ue to
implementation efficiency. Starting with C and others in 1960s up to
1990s. But as time went on, this concept in computer languages are
gradually disappearing, as they should.
Other langs that have this =E2=80=9Creference=E2=80=9D concept as ESSENTIAL=
part of
the semantic of the language, includes: C, C++, Java, Perl, Common
Lisp. (of course, each using different terminologies, and each lang
faction will gouge the other faction's eyes out about what is the true
meaning of terms like =E2=80=9Creference=E2=80=9D, =E2=80=9Cobject=E2=80=9D=
, =E2=80=9Clist/sequence/vector/
array/hash=E2=80=9D, and absolutely pretend other meanings do not exist.
(partly due to, their ignorance of langs other than their own, partly,
due to male power struggle nature.))
Languages that do not have any =E2=80=9Creference=E2=80=9D or =E2=80=9Cobje=
ct=E2=80=9D, or otherwise
does not require the programer to have some internal model of source
code, are: Mathematica, JavaScript, PHP. (others may include TCL,
possibly assembly langs.)
For some detail on this, see: Jargons And High Level Languages and
Hardware Modeled Computer Languages.
---------------------------
(perm url of this essay can be found on my website.)
Xah
=E2=88=91 http://xahlee.org/
=E2=98=84
------------------------------
Date: Tue, 02 Feb 2010 18:55:34 -0800
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: Want your opinion on @ARGV file globbing
Message-Id: <4b68e53c$0$6367$ed362ca5@nr5-q3a.newsreader.com>
Jürgen Exner wrote:
>
> Yes, you are. There is nothing wrong with the original version of your
> script and he has a problem with his shell, not with your Perl program.
> The correct solution is the same as for any program on UNIX when the
> shell complains about a too long arg list: use the find utility with the
> execute option.
Many programs do different things if invoked once on 16,000 files,
versus 16,000 times on one file each. Take "sort", for example.
Xho
------------------------------
Date: Tue, 02 Feb 2010 18:53:52 -0800
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: Want your opinion on @ARGV file globbing
Message-Id: <4b68e53a$0$22851$ed362ca5@nr5-q3a.newsreader.com>
jl_post@hotmail.com wrote:
> So to work around that problem, I wrote my script so that it only
> did file globbing if it was running on a Windows platform, like this:
>
> if ($^O =~ m/^MSWin/i)
> {
> @ARGV = map glob, @ARGV; # for DOS globbing
> }
>
> This way, input arguments won't get "double-globbed."
>
> Happy with this, I sent my script to the person who needed it. He
> responded by saying that "the argument list [was] too long." It turns
> out that the wildcard expression he was using expanded out to nearly
> 16,000 files, which caused the Unix shell he was using to refuse to
> run the resulting (long) command line.
>
> So I made a quick change to my script: I removed the above if-
> check and advised him to pass in the wildcarded arguments surrounded
> by quotes. That way the shell wouldn't expand out the wildcards,
> leaving Perl to do it.
>
> That "work-around" worked great. But that led me to ask: In
> future scripts, should I include the check for $^O before calling glob
> ()? If I don't, then the files risk being "double-globbed" on Unix
> systems -- but if I do, then I run the risk of the shell refusing to
> call the script (without an available work-around).
If I am running a script on Linux, I'd generally expect it to work the
way almost every other Linux program works, and not double glob.
> Of course, this is often a moot point, as more than 99% of the
> input files I ever processed have no wildcard characters or spaces in
> their filenames. But that's a guarantee I can't always make.
I often process input files that do have spaces in them, because we have
network drives that are cross mounted on both Linux and Windows, and
Windows users often include spaces in their file names.
> Perhaps I could still call glob() by default on all systems, but
> include a command-line switch that forces that not to happen (in order
> to prevent double-globbing). That way, the switch could be mostly
> ignored, but it is there in case it's ever needed.
I'd probably reverse that, and have it manually glob only with the
switch. But I guess it depends on what you think would be more likely,
huge file lists or file lists with space/wildcards.
One thing to consider is failure mode. I think a "argument list too
long" error is more likely to be noticed and correctly interpreted and
acted upon than a program which silently tries to process a double
globbed, and hence incorrect, list of files.
>
> Or am I just overthinking this? After all, glob()bing @ARGV in all
> instances (that is, regardless of platform) has never given me a
> problem (yet).
Are you sure you would know if it had?
> Maybe I should just leave it in (to be called all the
> time) after all.
>
> What are your opinions on this? Is there a convention you use that
> addresses this issue? In there an alternate way you prefer to handle
> it?
I have some scripts which are routinely called on thousands of files.
However, when used routinely, all the files are in a standard location
following a standard naming convention. So I have the program look at
@ARGV, after all switches are processed, and if it has exactly 1
argument and that one argument looks like, say, "ProjectXXX", then it
automatically does @ARGV=glob"/aldfj/dsf/ad/sdf/$ARGV[0]/klj*/*.csv";
If you have highly specialized needs, then you do highly specialized things.
Xho
------------------------------
Date: Tue, 02 Feb 2010 19:43:00 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Want your opinion on @ARGV file globbing
Message-Id: <t1shm55un60hchbqmbvqkbvdend8h7pc3e@4ax.com>
Xho Jingleheimerschmidt <xhoster@gmail.com> wrote:
>Jürgen Exner wrote:
>>
>> Yes, you are. There is nothing wrong with the original version of your
>> script and he has a problem with his shell, not with your Perl program.
>> The correct solution is the same as for any program on UNIX when the
>> shell complains about a too long arg list: use the find utility with the
>> execute option.
>
>Many programs do different things if invoked once on 16,000 files,
>versus 16,000 times on one file each. Take "sort", for example.
Obviously. However in that case you need a different method to pass that
list of 16000 values anyway because is it not possible to pass them as
command line arguments.
Writing them to a file and loading that file via a -f option comes to
mind as one simple and effective solution. I am sure there are others.
jue
------------------------------
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 2802
***************************************
