[32377] in Perl-Users-Digest
Perl-Users Digest, Issue: 3644 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Mar 19 21:09:26 2012
Date: Mon, 19 Mar 2012 18:09:09 -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 Mon, 19 Mar 2012 Volume: 11 Number: 3644
Today's topics:
Re: Embedding code in qq{}? <uri@stemsystems.com>
Re: Embedding code in qq{}? (Tim McDaniel)
Re: Embedding code in qq{}? (Tim McDaniel)
Re: Embedding code in qq{}? <uri@stemsystems.com>
Re: Embedding code in qq{}? <uri@stemsystems.com>
Re: Embedding code in qq{}? (Tim McDaniel)
Re: Embedding code in qq{}? (Tim McDaniel)
Re: Embedding code in qq{}? <ben@morrow.me.uk>
Re: Embedding code in qq{}? <ben@morrow.me.uk>
Re: Embedding code in qq{}? <rweikusat@mssgmbh.com>
error trapping with eval <cartercc@gmail.com>
Re: error trapping with eval <rweikusat@mssgmbh.com>
Re: error trapping with eval <ben@morrow.me.uk>
Re: error trapping with eval (Tim McDaniel)
new perl book: replacing java in the enterprise with pe <gavcomedy@gmail.com>
Re: yet another question about numbers and strings <cartercc@gmail.com>
Re: yet another question about numbers and strings <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 18 Mar 2012 22:05:36 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Embedding code in qq{}?
Message-Id: <87haxltken.fsf@stemsystems.com>
>>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
BM> Quoth Uri Guttman <uri@stemsystems.com>:
>>
>> it still is a poor construct to use. there is an Interpolate module that
>> does this with better syntax $() iirc. perl6 properly supports this idea
>> as well.
BM> Oddly there doesn't seem to be, at least not on CPAN. In any case, it
BM> looks like this:
http://search.cpan.org/~mjd/Interpolation-0.53/Interpolation.pm
wrong name from my memory. this does all sorts of stuff like that.
uri
------------------------------
Date: Mon, 19 Mar 2012 02:21:42 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Embedding code in qq{}?
Message-Id: <jk657m$383$1@reader1.panix.com>
In article <86fwd5wl9d.fsf@red.stonehenge.com>,
Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>> "Tim" == Tim McDaniel <tmcd@panix.com> writes:
>
>Tim> print "scalar: ", ${tester()}, "\n";
>
>I'm amazed this works.
Why? The basic syntax for a scalar variable is $identifier, and man
perlref (Perl 5.10):
"Anywhere you'd put an identifier (or chain of identifiers) as part of
a variable or subroutine name, you can replace the identifier with a
BLOCK returning a reference of the correct type."
So replace "identifier" with a BLOCK. The BLOCK is
{tester()}
That sub returns the required reference to a scalar. It's no more
surprising than
${\(22)}
which is what it returns.
>Tim> print "array: ", @{tester()}, "\n";
>
>You forgot the square brackets.
No, I didn't. They are not required -- just a BLOCK that returns a
reference to an array. Of course, square brackets are a convenient
way to generate such a reference. Had tester been called in an array
context (which, as I noted, in retrospect would make no sense), it
would have returned [ 11, 12, 13 ].
I just ran this in Perl 5.10:
#! /usr/bin/perl
use strict;
use warnings;
sub poit { return [ 11, 22, 33]; }
sub pondering { my @a = (44, 55, 66); return \@a; }
print join(' narf ', @{poit();}), "\n";
print join(' zort ', @{pondering();}), "\n";
exit 0;
Output:
$ perl local/test/090.pl
11 narf 22 narf 33
44 zort 55 zort 66
In the "pondering" case, nary a square bracket in sight.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 19 Mar 2012 02:55:42 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Embedding code in qq{}?
Message-Id: <jk677e$9vk$1@reader1.panix.com>
In article <87pqc9trvt.fsf@stemsystems.com>,
Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
>
> TM> In article <87ty1lu2z7.fsf@stemsystems.com>,
> TM> Uri Guttman <uri@stemsystems.com> wrote:
> >> bad answer. first off it isn't needed as the /e modifier to
> >> s/// does it.
>
> TM> Which I tried to make clear but didn't. I wasn't trying to
> TM> address the s/// case; everyone who pointed out s///e covered
> TM> it quite nicely. I was trying to cover the case of being
> TM> outside the RHS of s///.
>
>but the OP was only really asking about s///.
I'm not allowed to bring up new stuff? I'm only allowed to address
the one case that someone asks about and not tangent off onto
something else?
And in any event, it works on the right-hand side of s///:
#! /usr/bin/perl
use strict;
use warnings;
$_ = 'abcde';
s/c/ before ${my $q = 23; \(9+$q)} after /;
print "$_\n";
exit 0;
Output:
$ perl local/test/092.pl
ab before 32 after de
> TM> It does help clarify for me what ${...} means, that ... is
> TM> simply a block that returns a value.
>
>${foo} is not such a thing.
To repeat again, man perlref says it is.
Anywhere you'd put an identifier (or chain of identifiers) as part
of a variable or subroutine name, you can replace the identifier
with a BLOCK returning a reference of the correct type.
>the more i think about it, it isn't a true block in general. it is a
>dereference operation that allows statements. you can't last out of
>it
"Being able to last out of it" is not Perl's definition of block.
man perlsyn says
In Perl, a sequence of statements that defines a scope is called a
block. Sometimes a block is delimited by the file containing it
(in the case of a required file, or the program as a whole), and
sometimes a block is delimited by the extent of a string (in the
case of an eval).
But generally, a block is delimited by curly brackets, also known
as braces. We will call this syntactic construct a BLOCK.
As I explained before, it's a block just the same as do {...}.
You can't last out of do{...} either, or map or grep, but
perlfunc still explains the syntax as
do BLOCK
map BLOCK LIST
grep BLOCK LIST
or, for that matter,
if (EXPR) BLOCK
if (EXPR) BLOCK else BLOCK
if (EXPR) BLOCK elsif (EXPR) BLOCK ... else BLOCK
sub [NAME] BLOCK
or even the source file itself. There are all sorts of blocks you
can't last or next in. Are you saying that the body of a sub isn't a
block?
>(which you can from a bare block).
"last" is specifically a *loop* control structure, and a bare block,
as the perlfunc do docs says
"do BLOCK" does not count as a loop, so the loop control
statements "next", "last", or "redo" cannot be used to leave or
restart the block. See perlsyn for alternative strategies.
man perlsyn explains:
A BLOCK by itself (labeled or not) is semantically equivalent to a
loop that executes once. Thus you can use any of the loop control
statements in it to leave or restart the block. (Note that this
is NOT true in "eval{}", "sub{}", or contrary to popular belief
"do{}" blocks, which do NOT count as loops.) The "continue" block
is optional.
As for it being limited, as you note and I snipped: There are all
sorts of limitations in various contexts. The value of a sub is
limited too, if it returns something the caller will die on in
context.
As for it being useful: a general block in $BLOCK or @BLOCK is not in
practice useful, readable, helpful, or whatever. Still, that's how
it's explained in the documentation.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 19 Mar 2012 00:12:26 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Embedding code in qq{}?
Message-Id: <87d389tej9.fsf@stemsystems.com>
>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
TM> In article <87pqc9trvt.fsf@stemsystems.com>,
TM> Uri Guttman <uri@stemsystems.com> wrote:
>>>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
>>
TM> In article <87ty1lu2z7.fsf@stemsystems.com>,
TM> Uri Guttman <uri@stemsystems.com> wrote:
>> >> bad answer. first off it isn't needed as the /e modifier to
>> >> s/// does it.
>>
TM> Which I tried to make clear but didn't. I wasn't trying to
TM> address the s/// case; everyone who pointed out s///e covered
TM> it quite nicely. I was trying to cover the case of being
TM> outside the RHS of s///.
>>
>> but the OP was only really asking about s///.
TM> I'm not allowed to bring up new stuff? I'm only allowed to address
TM> the one case that someone asks about and not tangent off onto
TM> something else?
you can but it wasn't clear (as you said) that it was additional
stuff. and it wasn't the best stuff IMO either.
TM> And in any event, it works on the right-hand side of s///:
who ever said it wouldn't work there? the replacement side is a ""
string with some slight differences. but /e is better anyhow.
TM> To repeat again, man perlref says it is.
TM> Anywhere you'd put an identifier (or chain of identifiers) as part
TM> of a variable or subroutine name, you can replace the identifier
TM> with a BLOCK returning a reference of the correct type.
>> the more i think about it, it isn't a true block in general. it is a
>> dereference operation that allows statements. you can't last out of
>> it
TM> "Being able to last out of it" is not Perl's definition of block.
TM> man perlsyn says
TM> In Perl, a sequence of statements that defines a scope is called a
TM> block. Sometimes a block is delimited by the file containing it
TM> (in the case of a required file, or the program as a whole), and
TM> sometimes a block is delimited by the extent of a string (in the
TM> case of an eval).
TM> But generally, a block is delimited by curly brackets, also known
TM> as braces. We will call this syntactic construct a BLOCK.
and in most brace blocks you can last out. you can't in a dereference
block. hence it isn't the same as the others. you can't do various
things in the various types of blocks. it is good to know the difference
vs thinking they are all the same blocks.
>> (which you can from a bare block).
TM> "last" is specifically a *loop* control structure, and a bare block,
TM> as the perlfunc do docs says
TM> "do BLOCK" does not count as a loop, so the loop control
TM> statements "next", "last", or "redo" cannot be used to leave or
TM> restart the block. See perlsyn for alternative strategies.
TM> man perlsyn explains:
TM> A BLOCK by itself (labeled or not) is semantically equivalent to a
TM> loop that executes once. Thus you can use any of the loop control
TM> statements in it to leave or restart the block. (Note that this
TM> is NOT true in "eval{}", "sub{}", or contrary to popular belief
TM> "do{}" blocks, which do NOT count as loops.) The "continue" block
TM> is optional.
and it doesn't say the ${} block is either case.
uri
------------------------------
Date: Mon, 19 Mar 2012 00:14:51 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Embedding code in qq{}?
Message-Id: <878vixtef8.fsf@stemsystems.com>
>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
TM> In article <86fwd5wl9d.fsf@red.stonehenge.com>,
TM> Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>>> "Tim" == Tim McDaniel <tmcd@panix.com> writes:
>>
Tim> print "scalar: ", ${tester()}, "\n";
>>
>> I'm amazed this works.
TM> Why? The basic syntax for a scalar variable is $identifier, and man
TM> perlref (Perl 5.10):
please put your sarcasm detector on high gain. do you realize who you
replied to?
Tim> print "array: ", @{tester()}, "\n";
>>
>> You forgot the square brackets.
TM> No, I didn't. They are not required -- just a BLOCK that returns a
TM> reference to an array. Of course, square brackets are a convenient
TM> way to generate such a reference. Had tester been called in an array
TM> context (which, as I noted, in retrospect would make no sense), it
TM> would have returned [ 11, 12, 13 ].
without the [] it isn't close to the idiom being discussed. and as i
mentioned it wasn't in "" so it really bypasses the idiom. a plain deref
is just a plain deref, nothing to jump up and down about.
TM> I just ran this in Perl 5.10:
TM> In the "pondering" case, nary a square bracket in sight.
you are wandering in the wilderness. please go home! :)
uri
------------------------------
Date: Mon, 19 Mar 2012 06:42:10 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Embedding code in qq{}?
Message-Id: <jk6kg1$l5k$1@reader1.panix.com>
In article <878vixtef8.fsf@stemsystems.com>,
Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "TM" == Tim McDaniel <tmcd@panix.com> writes:
>
> TM> In article <86fwd5wl9d.fsf@red.stonehenge.com>,
> TM> Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> >>>>>>> "Tim" == Tim McDaniel <tmcd@panix.com> writes:
> >>
> Tim> print "scalar: ", ${tester()}, "\n";
> >>
> >> I'm amazed this works.
>
> TM> Why? The basic syntax for a scalar variable is $identifier,
> TM> and man perlref (Perl 5.10):
>
>please put your sarcasm detector on high gain. do you realize who you
>replied to?
Of course I realize. Given the man page quotations that I've posted
that some people have ignored, and the test programs and output that
I've posted that some people have ignored, it wouldn't surprise me at
all if even Randal were to join that pack.
> Tim> print "array: ", @{tester()}, "\n";
> >>
> >> You forgot the square brackets.
>
> TM> No, I didn't.
>
>without the [] it isn't close to the idiom being discussed.
I'm not discussing the idiom per se, but the general case that
explains it and much else.
>and as i mentioned it wasn't in "" so it really bypasses the idiom.
The behavior in "..." is a simple consequence of interpolating a
scalar or array in a string.
>you are wandering in the wilderness. please go home!
I'm sorry that I yet fail see by what authority you order me out of
the newsgroup. But if you post it, I'll be sure to follow the fashion
by ignoring it, misreading it, and shifting the goalposts.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 19 Mar 2012 07:00:28 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Embedding code in qq{}?
Message-Id: <jk6lic$1h3$1@reader1.panix.com>
I come to despise long chains of replies with several levels of
quoting all going over the same points, or people shifting goalposts
or going on into more false things.
I believe that I have adequately demonstrated, by quotations from man
pages and from test programs,
- $BLOCK, @BLOCK, and the rest take a BLOCK as defined by Perl,
so long as the BLOCK finishes with a reference of the type demanded
by the sigil
- they may be used as values in expressions whever a similar variable
might be used
- someone else pointed out that only $BLOCK and @BLOCK may be
interpolated into strings -- thank you for that. (I'm sorry I've
forgotten who, and I can't check while composing an article). I
assume the same is true for the right-hand side of s///
- I think it's not a particularly good idea except in certain simple
cases -- removing the BLOCK and assigning a variable before would
usually be clearer
I don't see much point in going on, unless someone posts something
new and false.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 19 Mar 2012 16:43:23 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Embedding code in qq{}?
Message-Id: <ba4k39-51o.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
>
> I don't see much point in going on, unless someone posts something
> new and false.
This statement is false.
(Or, if you prefer, 'This statement is unprovable.'.)
Ben
------------------------------
Date: Mon, 19 Mar 2012 16:40:29 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Embedding code in qq{}?
Message-Id: <t44k39-51o.ln1@anubis.morrow.me.uk>
Quoth tmcd@panix.com:
>
> I'm sorry that I yet fail see by what authority you order me out of
> the newsgroup. But if you post it, I'll be sure to follow the fashion
> by ignoring it, misreading it, and shifting the goalposts.
Careful. Insulting long-time regulars, even if you think they're clearly
in the wrong, is a sure way to end up in lots of killfiles.
Ben
------------------------------
Date: Mon, 19 Mar 2012 16:50:16 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Embedding code in qq{}?
Message-Id: <87obrs1qnr.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth tmcd@panix.com:
>> I'm sorry that I yet fail see by what authority you order me out of
>> the newsgroup. But if you post it, I'll be sure to follow the fashion
>> by ignoring it, misreading it, and shifting the goalposts.
>
> Careful. Insulting long-time regulars, even if you think they're clearly
> in the wrong, is a sure way to end up in lots of killfiles.
Someone who consistently behaves as abusive as Uri Guttman has every
reason to be happy if he just ends up in a lot of killfiles, as
opposed to at the receiving end of a lot of lawsuits.
------------------------------
Date: Mon, 19 Mar 2012 07:45:44 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: error trapping with eval
Message-Id: <26254149.125.1332168344678.JavaMail.geo-discussion-forums@ynjw14>
What is the functional difference between these two forms, the first using =
OR and the second using IF/ELSE? I can't see any difference, but if there i=
s I would appreciate a more experienced hand giving me a heads up. Also, if=
one style is more common that the other, is there a good reason for that?
Thanks, CC.
----------code below------------
use strict;
use warnings;
print "Enter number 1: ";
chomp ( my $number1 =3D <STDIN>);
print "Enter number 2: ";
chomp ( my $number2 =3D <STDIN>);
my $number3 =3D 'NAN';
print "number 1: $number1, number 2: $number2, number 3: $number3\n";
print "\nEXAMPLE 1\n";
eval { $number3 =3D $number1 / $number2; 1;} or
do { warn "division by zero - $@\n"; };
print "$number3\n";
print "\nEXAMPLE 2\n";
if ( eval { $number3 =3D $number1 / $number2; 1 } ) { }
else { warn "division by zero =3D $@\n"; }
print "$number3\n";
print "\nexiting\n";
exit(0);
------------------------------
Date: Mon, 19 Mar 2012 15:02:34 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: error trapping with eval
Message-Id: <874ntk3a7p.fsf@sapphire.mobileactivedefense.com>
ccc31807 <cartercc@gmail.com> writes:
> What is the functional difference between these two forms, the first
> using OR and the second using IF/ELSE? I can't see any difference,
> but if there is I would appreciate a more experienced hand giving me
> a heads up. Also, if one style is more common that the other, is
> there a good reason for that?
[...]
> print "\nEXAMPLE 1\n";
> eval { $number3 = $number1 / $number2; 1;} or
> do { warn "division by zero - $@\n"; };
> print "$number3\n";
>
> print "\nEXAMPLE 2\n";
> if ( eval { $number3 = $number1 / $number2; 1 } ) { }
> else { warn "division by zero = $@\n"; }
> print "$number3\n";
I have no idea which style is more common (I suspect that latter
because it contains more brackets), although the redundant do { }
in the first is already a nice obfuscation. Since there is no way to
code inside the eval can invoke a destructor, the misguided return
value hack in order to work around broken destructors is useless.
Leaving this aside, three variants which are not primarily intended to
throw sand into the eyes of an observer so that he no longer sees what
is going on would be:
eval { $number3 = $number1 / $number2; 1 }
or warn("something failed: $@");
and
unless (eval { ... }) {
warn("something failed: $@");
}
warn("something failed: $@") unless eval { ... };
I'd prefer the first since the 2nd has a redundant block and the third
emphasizes the failure code instead of the action which is actually
supposed to be performed.
BTW:
To make them more reliable and consistent, several changes have been
made to how die, warn, and $@ behave.
* When an exception is thrown inside an eval, the exception is no
longer at risk of being clobbered by destructor code running
during unwinding.
[...]
Exceptions thrown from object destructors no longer modify the
$@ of the surrounding context. (If the surrounding context was
exception unwinding, this used to be another way to clobber the
exception being thrown.)
http://perldoc.perl.org/5.14.0/perldelta.html#Exception-Handling
(released on 2011/05.14)
------------------------------
Date: Mon, 19 Mar 2012 16:56:23 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: error trapping with eval
Message-Id: <n25k39-51o.ln1@anubis.morrow.me.uk>
Quoth ccc31807 <cartercc@gmail.com>:
> What is the functional difference between these two forms, the first
> using OR and the second using IF/ELSE?
There is no functional difference.
> I can't see any difference, but
> if there is I would appreciate a more experienced hand giving me a heads
> up. Also, if one style is more common that the other, is there a good
> reason for that?
<snip>
>
> print "\nEXAMPLE 1\n";
> eval { $number3 = $number1 / $number2; 1;} or
> do { warn "division by zero - $@\n"; };
I tend to avoid using 'do' for control flow. I feel it's clearer to
restrict its use to cases where the block is returning a value.
In this case, since it contains only a single statement, it is
unnecessary:
eval {...}
or warn ...;
> print "$number3\n";
>
> print "\nEXAMPLE 2\n";
> if ( eval { $number3 = $number1 / $number2; 1 } ) { }
> else { warn "division by zero = $@\n"; }
This is an extremely roundabout way to spell 'unless'.
unless (eval {...}) {
warn ...;
}
though even then I don't like multiple statements inside the condition
of an 'if'.
In this particular case, $number3 should never be undef, so
my $number3 = eval { $number1 / $number2 };
defined $number3 or warn ...;
looks clearest to me. If I wanted to replace the 'warn' with more
statements I would replace the 'or' with 'unless':
my $number3 = eval { $number1 / $number2 };
unless (defined $number3) {
warn ...;
...;
}
If I wanted more statements in the 'eval', I'd use Try::Tiny:
try {
$number3 = $number1 / $number2;
...;
}
catch {
warn ...;
};
> exit(0);
This is unnecessary.
Ben
------------------------------
Date: Mon, 19 Mar 2012 19:11:58 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: error trapping with eval
Message-Id: <jk80du$en3$1@reader1.panix.com>
In article <n25k39-51o.ln1@anubis.morrow.me.uk>,
Ben Morrow <ben@morrow.me.uk> wrote:
>
>Quoth ccc31807 <cartercc@gmail.com>:
>> exit(0);
>
>This is unnecessary.
I'd had the impression that, if you fell off the end of the main
program, the exit code was the value of the last expression, rather
like sub or do. Experimentally, that's not the case in Perl 5.10.
I see from "man perlrun"
If the program is syntactically correct, it is executed. If the
program runs off the end without hitting an exit() or die()
operator, an implicit exit(0) is provided to indicate successful
completion.
It may be pedantic, but I still prefer to put
exit 0;
at the end of my program, just like I always use "return" to return a
value from a sub even where it's not tecnically needed.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 19 Mar 2012 11:16:15 -0700 (PDT)
From: quiet_lad <gavcomedy@gmail.com>
Subject: new perl book: replacing java in the enterprise with perl and cutting cpu and resource usage 80%
Message-Id: <20574321.1272.1332180975348.JavaMail.geo-discussion-forums@pbbpk10>
write it now perl demigods!
------------------------------
Date: Mon, 19 Mar 2012 14:20:41 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: yet another question about numbers and strings
Message-Id: <601cead0-1310-4232-a513-0812b2a2f2aa@er9g2000vbb.googlegroups.com>
As a rule, I do this kind of thing in two easy steps: (1) grab all the
data from the database using SQL select statements (which can be
arbitrarily complex) and stuff it into a reference to a hash, then (2)
iterate through the reference to the hash manipulating each row (which
normally means selectively building one or more data structures,
either as hashes or hash references.
I don't think that I understand your question. To me, you query a
database to obtain data, which you plan to use in some manner to
generate some output. If you select data, you can filter the rows by
some kind of WHERE statement. Given your code, it looks to me like,
instead of using some kind of WHERE clause, you are operating on each
row in place.
I have found that I always use a hashref to get data from a database.
The vast majority of the time, it's a two level hash, with the first
level consisting of the record IDs as keys, and the second level
consisting of the column heads. If you read the data into memory as a
hashref, I don't think you would have this problem, since all the keys
would be strings.
On Mar 15, 8:38=A0am, hy...@lactose.homelinux.net (hymie!) wrote:
> I have an MSSQL database. =A0It includes a field for ID numbers
> that are about 18 digits long.
Your record ID is essentially a string, unless for some very peculiar
and odd reason you want to perform arithmetic operations on your
record IDs.
> I have a generic searching tool that I use on this database. =A0It basica=
lly
> does this:
If you grab the data as a hashref, you can do something like this:
foreach my $recordID (keys %{$hashref})
{
if ($recordID =3D~ /generic searching tool/)
{
do_something_sub($hashref->{$recordID});
}
}
> Again, I have no idea if this means MSSQL is sending me data in exp forma=
t,
> or if Perl is doing the changing for me.
I don't do MSSQL, but I think you could completely sidestep the
problem with a hashref.
> But if anybody knows how to fix it, I'd be grateful.
Is there any reason that you don't won't to grab all the data from the
database and stuff it into your machine's memory? Is there some reason
that you can't use the usual SQL commands for selection but have to
use a hand rolled script for the selection?
CC.
------------------------------
Date: Mon, 19 Mar 2012 23:09:48 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: yet another question about numbers and strings
Message-Id: <suqk39-qpu.ln1@anubis.morrow.me.uk>
Quoth ccc31807 <cartercc@gmail.com>:
> On Mar 15, 8:38 am, hy...@lactose.homelinux.net (hymie!) wrote:
> > I have an MSSQL database. It includes a field for ID numbers
> > that are about 18 digits long.
>
> Your record ID is essentially a string, unless for some very peculiar
> and odd reason you want to perform arithmetic operations on your
> record IDs.
>
> > I have a generic searching tool that I use on this database. It basically
> > does this:
>
> If you grab the data as a hashref, you can do something like this:
This would have made no difference in the OP's case. The problem was
(essentially) a bug in DBD::Sybase, which was losing information before
the data ever got back to Perl.
Ben
------------------------------
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 3644
***************************************
