[27820] in Perl-Users-Digest
Perl-Users Digest, Issue: 9184 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Apr 21 03:05:49 2006
Date: Fri, 21 Apr 2006 00:05:05 -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, 21 Apr 2006 Volume: 10 Number: 9184
Today's topics:
new CPAN modules at Fri Apr 21 2006 (Randal Schwartz)
Re: show hidden value in variable.. with mysql.. FIXED joe.henderson1@
Re: Term::ReadKey on Win? 5.005 vs 5.8.8? <nospam-abuse@ilyaz.org>
Re: Term::ReadKey on Win? 5.005 vs 5.8.8? <nospam-abuse@ilyaz.org>
Tracing SQL queries done via DBI (mod_perl) <ignoramus8495@NOSPAM.8495.invalid>
Re: Tracing SQL queries done via DBI (mod_perl) <sherm@dot-app.org>
Re: Tracing SQL queries done via DBI (mod_perl) <1usa@llenroc.ude.invalid>
Re: Tracing SQL queries done via DBI (mod_perl) <ignoramus8495@NOSPAM.8495.invalid>
Re: Tracing SQL queries done via DBI (mod_perl) <sherm@dot-app.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 21 Apr 2006 04:42:05 GMT
From: merlyn@stonehenge.com (Randal Schwartz)
Subject: new CPAN modules at Fri Apr 21 2006
Message-Id: <Iy22E5.pMr@zorch.sf-bay.org>
The following modules have recently been added to or updated in the
Comprehensive Perl Archive Network (CPAN). You can install them using the
instructions in the 'perlmodinstall' page included with your Perl
distribution.
Text-NSP-0.91
http://search.cpan.org/~tpederse/Text-NSP-0.91/
The Ngram Statistic Package allows a user to count sequences of words in large corpora of text, and measure their association.
----
JSON-PC-0.01
http://search.cpan.org/~makamaka/JSON-PC-0.01/
fast JSON Parser and Converter
----
Class-CGI-0.12
http://search.cpan.org/~ovid/Class-CGI-0.12/
Fetch objects from your CGI object
----
Test-MockObject-1.06
http://search.cpan.org/~chromatic/Test-MockObject-1.06/
Perl extension for emulating troublesome interfaces
----
SUPER-1.12
http://search.cpan.org/~chromatic/SUPER-1.12/
control superclass method dispatch
----
Sub-Uplevel-0.10
http://search.cpan.org/~dagolden/Sub-Uplevel-0.10/
apparently run a function in a higher stack frame
----
String-Random-0.21
http://search.cpan.org/~steve/String-Random-0.21/
Perl module to generate random strings based on a pattern
----
Test-Deep-0.095
http://search.cpan.org/~fdaly/Test-Deep-0.095/
Extremely flexible deep comparison
----
RT-Client-REST-0.05
http://search.cpan.org/~dmitri/RT-Client-REST-0.05/
talk to RT installation using REST protocol.
----
Class-MOP-0.25
http://search.cpan.org/~stevan/Class-MOP-0.25/
A Meta Object Protocol for Perl 5
----
Wx-0.49_03
http://search.cpan.org/~mbarbon/Wx-0.49_03/
interface to the wxWidgets cross-platform GUI toolkit
----
Device-Gsm-1.41
http://search.cpan.org/~cosimo/Device-Gsm-1.41/
Perl extension to interface GSM cellular / modems
----
Device-Modem-1.47
http://search.cpan.org/~cosimo/Device-Modem-1.47/
Perl extension to talk to modem devices connected via serial port
----
IO-Socket-TIPC-0.02
http://search.cpan.org/~infinoid/IO-Socket-TIPC-0.02/
Perl sockets for TIPC
----
Net-Proxy-0.06
http://search.cpan.org/~book/Net-Proxy-0.06/
Framework for proxying network connections in many ways
----
OpenGuides-0.53
http://search.cpan.org/~dom/OpenGuides-0.53/
A complete web application for managing a collaboratively-written guide to a city or town.
----
Class-CGI-0.11
http://search.cpan.org/~ovid/Class-CGI-0.11/
Fetch objects from your CGI object
----
Regexp-Assemble-0.25
http://search.cpan.org/~dland/Regexp-Assemble-0.25/
Assemble multiple Regular Expressions into a single RE
----
HTML-TreeBuilder-XPath-0.03
http://search.cpan.org/~mirod/HTML-TreeBuilder-XPath-0.03/
add XPath support to HTML::TreeBuilder
----
Task-SOSA-1.04
http://search.cpan.org/~ghenry/Task-SOSA-1.04/
Install all the CPAN modules needed by SOSA
----
Email-Send-2.05
http://search.cpan.org/~cwest/Email-Send-2.05/
Simply Sending Email
----
Class-DBI-Plugin-AggregateFunction-0.02
http://search.cpan.org/~asakura/Class-DBI-Plugin-AggregateFunction-0.02/
aggregate function for Class::DBI
----
Class-DBI-Sweet-Pie-0.04
http://search.cpan.org/~asakura/Class-DBI-Sweet-Pie-0.04/
aggregate function for Class::DBI::Sweet
----
Module-Build-Convert-0.27
http://search.cpan.org/~schubiger/Module-Build-Convert-0.27/
Makefile.PL to Build.PL converter
----
POE-Component-Client-Whois-1.04
http://search.cpan.org/~bingos/POE-Component-Client-Whois-1.04/
A one shot non-blocking RFC 812 WHOIS query.
----
String-CRC32-1.4
http://search.cpan.org/~soenke/String-CRC32-1.4/
Perl interface for cyclic redundency check generation
----
Module-ThirdParty-0.15
http://search.cpan.org/~saper/Module-ThirdParty-0.15/
Provide information for 3rd party modules (outside CPAN)
----
Class-DBI-Plugin-Param-0.03
http://search.cpan.org/~naoya/Class-DBI-Plugin-Param-0.03/
Adding param() method to your CDBI object.
If you're an author of one of these modules, please submit a detailed
announcement to comp.lang.perl.announce, and we'll pass it along.
print "Just another Perl hacker," # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: Fri, 21 Apr 2006 01:19:19 GMT
From: joe.henderson1@
Subject: Re: show hidden value in variable.. with mysql.. FIXED
Message-Id: <bmcg42l68m1o94s1bernrponvv9i1sv9kk@4ax.com>
On Fri, 21 Apr 2006 01:02:53 GMT, "John W. Krahn"
<someone@example.com> wrote:
>joe.henderson1@ wrote:
>>
>> All,
>>
>> Thanks for all your help.. I found out what the problem was...
>>
>> Their was a hidden "null" in the variable.. hex code of "00"..
>
>That's what I thought, it was "\0" and not "\o". :-)
Hmm... Good point... I did not retain the terminal logs so I'll give
this one to you...
But my question remains... "how did that null value get into that
string"...?
>
>
>John
thanks,
Joe
------------------------------
Date: Fri, 21 Apr 2006 01:20:52 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Term::ReadKey on Win? 5.005 vs 5.8.8?
Message-Id: <e29c1k$1ue9$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Sisyphus
<sisyphus1@nomail.afraid.org>], who wrote in article <444816be$0$29881$afc38c87@news.optusnet.com.au>:
> > Could you check the file name to
> > which STDIN is connected? On OS/2 POSIX::ttyname() would work; do not
> > know about Win*...
> I don't know about Windows either. POSIX::ttyname() is not implemented.
Anyway, there must be a way to list (names of) files opened by a
process. Usually named lsof or similarly.
> I thought it might be noteworthy that the ord() for the 'Enter' and 'Ctrl-M'
> keys seemed to change from 13 to 10. No matter.
well, it must be 10 in cooked non-binary mode. The surprise is that
it is 13 in raw mode... Another surprise is that Win-specific code is
smart enough to ignore text-mode on raw filehandles...
Thanks,
Ilya
------------------------------
Date: Fri, 21 Apr 2006 01:25:52 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Term::ReadKey on Win? 5.005 vs 5.8.8?
Message-Id: <e29cb0$1ujq$1@agate.berkeley.edu>
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Dr.Ruud
<rvtol+news@isolution.nl>], who wrote in article <e29aj7.1ck.1@news.isolution.nl>:
> I read the code for a few minutes and then tested this:
Is not a part of your message missing?
> C:\>perl -MTerm::ReadKey -wle "open $in, '+< CONIN$' or die $!;
> ReadMode 4, $in;
> $|=1;
> print ord while defined($_=ReadKey 0)"
This has a low probablity to be useful. Whatever happens is a side
effect of changing ReadMode on one filehandle, and testing the results
on another. As Sysiphus already tested, STDIN opened to "default TTY"
acts the same as CONIN$...
Thanks,
Ilya
------------------------------
Date: Fri, 21 Apr 2006 01:46:59 GMT
From: Ignoramus8495 <ignoramus8495@NOSPAM.8495.invalid>
Subject: Tracing SQL queries done via DBI (mod_perl)
Message-Id: <nQW1g.198354$_X1.12942@fe05.usenetserver.com>
I would like to have a log of all SQL queries that my scripts do via
DBI. (80k+ of perl code, mod_perl)
I have one entry point (module) whose job is to give the database
handle to everyone. So I have control over the handle.
There is a trace() method on DBI, however, it does not properly print
the statements that were prepare'd a long time ago and are repeatedly
execute'd.
So... What am I missing?
Can I somehow track all statements that are executed?
thanks
i
------------------------------
Date: Thu, 20 Apr 2006 22:08:39 -0400
From: Sherm Pendley <sherm@dot-app.org>
Subject: Re: Tracing SQL queries done via DBI (mod_perl)
Message-Id: <m2mzefd6jc.fsf@Sherm-Pendleys-Computer.local>
Ignoramus8495 <ignoramus8495@NOSPAM.8495.invalid> writes:
> I would like to have a log of all SQL queries that my scripts do via
> DBI. (80k+ of perl code, mod_perl)
>
> I have one entry point (module) whose job is to give the database
> handle to everyone. So I have control over the handle.
>
> There is a trace() method on DBI, however, it does not properly print
> the statements that were prepare'd a long time ago and are repeatedly
> execute'd.
>
> So... What am I missing?
Does this help?
<http://perl.apache.org/docs/1.0/guide/databases.html#Debugging_code_which_deploys_DBI>
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: Fri, 21 Apr 2006 02:37:14 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Tracing SQL queries done via DBI (mod_perl)
Message-Id: <Xns97ABE61CD3E42asu1cornelledu@127.0.0.1>
Sherm Pendley <sherm@dot-app.org> wrote in
news:m2mzefd6jc.fsf@Sherm-Pendleys-Computer.local:
> Ignoramus8495 <ignoramus8495@NOSPAM.8495.invalid> writes:
>
>> I would like to have a log of all SQL queries that my scripts do via
>> DBI. (80k+ of perl code, mod_perl)
>>
>> I have one entry point (module) whose job is to give the database
>> handle to everyone. So I have control over the handle.
>>
>> There is a trace() method on DBI, however, it does not properly print
>> the statements that were prepare'd a long time ago and are repeatedly
>> execute'd.
>>
>> So... What am I missing?
>
> Does this help?
>
> <http://perl.apache.org/docs/1.0/guide/databases.html#Debugging_code_which_deploys_DBI>
I doubt it:
http://search.cpan.org/~timb/DBI-1.50/DBI.pm
Trace Flags
Trace flags are used to enable tracing of specific activities
within the DBI and drivers. The DBI defines some trace flags
and drivers can define others. DBI trace flag names begin with
a capital letter and driver specific names begin with a lowercase
letter, as usual.
Curently the DBI only defines two trace flags:
ALL - turn on all DBI and driver flags (not recommended)
SQL - trace SQL statements executed (not yet implemented)
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, 21 Apr 2006 04:42:57 GMT
From: Ignoramus8495 <ignoramus8495@NOSPAM.8495.invalid>
Subject: Re: Tracing SQL queries done via DBI (mod_perl)
Message-Id: <lpZ1g.5397$mg7.1143@fe56.usenetserver.com>
On Thu, 20 Apr 2006 22:08:39 -0400, Sherm Pendley <sherm@dot-app.org> wrote:
> Ignoramus8495 <ignoramus8495@NOSPAM.8495.invalid> writes:
>
>> I would like to have a log of all SQL queries that my scripts do via
>> DBI. (80k+ of perl code, mod_perl)
>>
>> I have one entry point (module) whose job is to give the database
>> handle to everyone. So I have control over the handle.
>>
>> There is a trace() method on DBI, however, it does not properly print
>> the statements that were prepare'd a long time ago and are repeatedly
>> execute'd.
>>
>> So... What am I missing?
>
> Does this help?
>
> <http://perl.apache.org/docs/1.0/guide/databases.html#Debugging_code_which_deploys_DBI>
>
I believe that it does not print SQL statements that were prepared a
long time ago, and are now being executed. It only says "executing",
but does not say what.
It is basically a glorified way of calling $dbh->trace( 3 ).
I could possibly make some complicated analysis tool matching
addresses of statement handles with previous output from prepare, but
that would be a pain with obvious problems (several processes could
have identical addresses occupied by different objects)
Example:
#!/usr/bin/perl
use Algebra::SqlAccess;
dbh->trace( 3 );
my $sth = dbh->prepare( "select count(*) from sessions" );
for( my $i = 0; $i < 3; $i++ ) {
$sth->execute;
$sth->finish;
}
manifold::~/tmp==>perl dbitest.pl
DBI::db=HASH(0x9ad30bc) trace level set to 0x0/3 (DBI @ 0x0/0) in
DBI 1.50-ithread (pid 29911)
-> prepare for DBD::mysql::db (DBI::db=HASH(0x9a8a150)~0x9ad30bc
'select count(*) from sessions') thr#9855008
dbih_setup_handle(DBI::st=HASH(0x9ad3284)=>DBI::st=HASH(0x9ad3404), DBD::mysql::st, 9ad3290, Null!)
dbih_make_com(DBI::db=HASH(0x9ad30bc), 9ada688, DBD::mysql::st,
248, 0) thr#9855008
dbd_st_prepare calling count_params (counting params emulation)
<- prepare= DBI::st=HASH(0x9ad3284) at dbitest.pl line 7
-> execute for DBD::mysql::st (DBI::st=HASH(0x9ad3284)~0x9ad3404)
thr#9855008
-> dbd_st_execute for 09ad344c
---> parse_params with statement select count(*) from sessions num
params 0
mysql_st_internal_execute
<- dbd_st_execute returning imp_sth->row_num 1
<- execute= 1 at dbitest.pl line 10
-> finish for DBD::mysql::st (DBI::st=HASH(0x9ad3284)~0x9ad3404)
thr#9855008
<- finish= 1 at dbitest.pl line 11
-> execute for DBD::mysql::st (DBI::st=HASH(0x9ad3284)~0x9ad3404)
thr#9855008
-> dbd_st_execute for 09ad344c
---> parse_params with statement select count(*) from sessions num
params 0
mysql_st_internal_execute
<- dbd_st_execute returning imp_sth->row_num 1
<- execute= 1 at dbitest.pl line 10
-> finish for DBD::mysql::st (DBI::st=HASH(0x9ad3284)~0x9ad3404)
thr#9855008
<- finish= 1 at dbitest.pl line 11
-> execute for DBD::mysql::st (DBI::st=HASH(0x9ad3284)~0x9ad3404)
thr#9855008
-> dbd_st_execute for 09ad344c
---> parse_params with statement select count(*) from sessions num
params 0
mysql_st_internal_execute
<- dbd_st_execute returning imp_sth->row_num 1
<- execute= 1 at dbitest.pl line 10
-> finish for DBD::mysql::st (DBI::st=HASH(0x9ad3284)~0x9ad3404)
thr#9855008
<- finish= 1 at dbitest.pl line 11
-> DESTROY for DBD::mysql::st (DBI::st=HASH(0x9ad3404)~INNER)
thr#9855008
<- DESTROY= undef
! -> DESTROY for DBD::mysql::db (DBI::db=HASH(0x9ad30bc)~INNER)
thr#9855008
&imp_dbh->mysql: 9ada6dc
! <- DESTROY= undef during global destruction
i
------------------------------
Date: Fri, 21 Apr 2006 01:09:54 -0400
From: Sherm Pendley <sherm@dot-app.org>
Subject: Re: Tracing SQL queries done via DBI (mod_perl)
Message-Id: <m2mzefh5ul.fsf@Sherm-Pendleys-Computer.local>
"A. Sinan Unur" <1usa@llenroc.ude.invalid> writes:
> Sherm Pendley <sherm@dot-app.org> wrote in
> news:m2mzefd6jc.fsf@Sherm-Pendleys-Computer.local:
>
>> Ignoramus8495 <ignoramus8495@NOSPAM.8495.invalid> writes:
>>
>>> I would like to have a log of all SQL queries that my scripts do via
>>> DBI. (80k+ of perl code, mod_perl)
>>>
>>> I have one entry point (module) whose job is to give the database
>>> handle to everyone. So I have control over the handle.
>>>
>>> There is a trace() method on DBI, however, it does not properly print
>>> the statements that were prepare'd a long time ago and are repeatedly
>>> execute'd.
>>>
>>> So... What am I missing?
>>
>> Does this help?
>>
>> <http://perl.apache.org/docs/1.0/guide/databases.html#Debugging_code_which_deploys_DBI>
>
> I doubt it:
>
> http://search.cpan.org/~timb/DBI-1.50/DBI.pm
>
> Trace Flags
>
> Trace flags are used to enable tracing of specific activities
> within the DBI and drivers. The DBI defines some trace flags
> and drivers can define others. DBI trace flag names begin with
> a capital letter and driver specific names begin with a lowercase
> letter, as usual.
>
> Curently the DBI only defines two trace flags:
>
> ALL - turn on all DBI and driver flags (not recommended)
> SQL - trace SQL statements executed (not yet implemented)
Yes, but Apache::DBI - mentioned in the link I gave - extends the basic
trace functionality to five different trace levels. I've not used it, but
my thinking is that, being specific to mod_perl, it may work better in
that environment than the "vanilla" DBI trace() function.
If nothing else, it wouldn't hurt to try it.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
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 V10 Issue 9184
***************************************
