[23668] in Perl-Users-Digest
Perl-Users Digest, Issue: 5875 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Nov 30 14:05:39 2003
Date: Sun, 30 Nov 2003 11:05:07 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 30 Nov 2003 Volume: 10 Number: 5875
Today's topics:
ANNOUNCE: Archive::Zip 1.09 <ned@bike-nomad.com>
binding ICMP to a specific IP address (Stuart Kendrick)
Re: binding ICMP to a specific IP address <usenet@morrow.me.uk>
character encodings <j.g.karssenberg@student.utwente.nl>
Re: character encodings <jurgenex@hotmail.com>
Re: character encodings <j.g.karssenberg@student.utwente.nl>
Re: character encodings <flavell@ph.gla.ac.uk>
Re: config::inifiles and retrieval of delimiter <joeminga@yahoo.com>
Convert::yEnc 1.01 <swmcd@TheWorld.com>
Re: DBI error handling <usenet@morrow.me.uk>
Deleting tmp-files of CGI.pm upload() <johanoberm@gmx.de>
Re: Deleting tmp-files of CGI.pm upload() (Malcolm Dew-Jones)
Re: Deleting tmp-files of CGI.pm upload() <usenet@morrow.me.uk>
Re: Deleting tmp-files of CGI.pm upload() (Malcolm Dew-Jones)
Re: Memory Allocation Error when to fetching BLOB field <Admin@goMonitor.com>
Re: Newsgroup Searching Program <mikeflan@earthlink.net>
Re: Perl unicode and :crlf, was Re: regexp: \x0a => \x0 <flavell@ph.gla.ac.uk>
Problem installing through PPM (Nilendu)
Re: Reading Dates from Excel-file <syscjm@gwu.edu>
Re: trouble with DBI/CGI <jwillmore@remove.adelphia.net>
Re: trouble with DBI/CGI (Sara)
Re: trouble with DBI/CGI <flavell@ph.gla.ac.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 27 Nov 2003 17:57:15 GMT
From: Ned Konz <ned@bike-nomad.com>
Subject: ANNOUNCE: Archive::Zip 1.09
Message-Id: <Hp6ED4.103L@zorch.sf-bay.org>
Archive::Zip v1.09 has been released.
This version improves the handling of damaged zips (requested by the Amavis
team), and adds methods to update a zip from a tree of files:
Among the changes since 1.08 are:
- Fixed handling of inserted garbage (as from viruses)
- Always check for local header signatures before using them
- Added updateMember() and updateTree() functions
- Added examples/mailZip.pl
- Added examples/updateTree.pl
- Fixed some potential but unreported bugs with function parameters like
'0'
- Removed stray warn() call
- Caught undef second arg to replaceMember()
- Fixed test suite run with spaces in build dir name (ticket 4214)
>From the README:
The Archive::Zip module allows a Perl program to create, manipulate,
read, and write Zip archive files.
Zip archives can be created, or you can read from existing zip files
or strings (using IO::Scalar). Once created, they can be written to
files, streams, or strings.
Members can be added, removed, extracted, replaced, rearranged, and
enumerated. They can also be renamed or have their dates, comments, or
other attributes queried or modified. Their data can be compressed or
uncompressed as needed. Members can be created from members in existing
Zip files, or from existing directories, files, or strings.
Directory trees can be added or extracted simply using special tree
routines.
This module uses the Compress::Zlib library to read and write the
compressed streams inside the files. Note that versions of Compress::Zlib
prior to 1.06 truncate data and should not be used.
Compress::Zlib prior to 1.08 caused crashes on some Windows systems.
Examples and helper libraries are given to show how:
* zip files can be read and written to strings
* zip files can be written in chunks to arbitrary functions
CHANGES SINCE v1.00:
1.09 Wed Nov 26 17:43:49 PST 2003
- Fixed handling of inserted garbage (as from viruses)
- Always check for local header signatures before using them
- Added updateMember() and updateTree() functions
- Added examples/mailZip.pl
- Added examples/updateTree.pl
- Fixed some potential but unreported bugs with function parameters like
'0'
- Removed stray warn() call
- Caught undef second arg to replaceMember()
1.08 Tue Oct 21 07:01:29 PDT 2003
- test noise fix from Michael Schwern (ticket 4174)
- FAQ NAME fix from Michael Schwern (ticket 4175)
1.07 Mon Oct 20 06:48:41 PDT 2003
- Added file attribute code by Maurice Aubrey
- Added FAQ about RedHat 9 build errors
- Added check for empty filenames
1.06 Thu Jul 17 11:06:18 PDT 2003
- Fixed seek use with IO::Scalar and IO::String
- Fixed use of binmode with pseudo-file handles
- Removed qr{} form for older Perl versions
- Changed rel2abs logic in _asLocalName() if there is a volume
- Fixed errors with making directories in extractMember() when none
provided
- Return AZ_OK in extractMemberWithoutPaths() if member is a directory
- Fixed problem in extractTree with blank directory becoming "." prefix
- Added examples/writeScalar2.pl to show how to use IO::String as
destination of Zip write
- Edited docs and FAQ to recommend against using absolute path names in
zip files.
1.05 Wed Sep 11 12:31:20 PDT 2002
- fixed untaint from 1.04
1.04 Wed Sep 11 07:22:04 PDT 2002
- added untaint of lastModFileDateTime
1.03 Mon Sep 2 20:42:43 PDT 2002
- Removed dependency on IO::Scalar
- Set required version of File::Spec to 0.8
- Removed tests of examples that needed IO::Scalar
- Added binmode() call to read/writeScalar examples
- Fixed addTree() for 5.005 compatibility (still untested with 5.004)
- Fixed mkdir() calls for 5.005
- Clarified documentation of tree operations
1.02 Fri Aug 23 17:07:22 PDT 2002
- Many changes for cross-platform use (use File::Spec everywhere)
- Separated POD from Perl
- Moved Archive::Zip::Tree contents into Archive::Zip
A::Z::Tree is now deprecated and will warn with -w
- Reorganized docs
- Added FAQ
- Added chunkSize() call to report current chunk size
and added C::Z BufSize patch from Yeasah Pell.
- Added fileName() to report last read zip file name
- Added capability to prepend data, like for SFX files
- Added examples/selfex.pl for self-extracting archives creation
- Added examples/zipcheck.pl for validity testing
- Made extractToFileNamed() set access/modification times
- Added t/testTree.t to test A::Z::Tree
- Fix/speed up memberNamed()
- Added Archive::Zip::MemberRead by Sreeji K. Das
- Added tempFile(), tempName()
- Added overwrite() and overwriteAs() to allow read/modify/write of zip
- added examples/updateZip.pl to show how to read/modify/write
1.01 Tue Apr 30 10:34:44 PDT 2002
- Changed mkpath call for directories to work with BSD/OS
- Changed tests to work with BSD/OS
COPYRIGHT:
Copyright (c) 2000-2003 Ned Konz. All rights reserved. This program is free
software; you can redistribute it and/or modify it under the same terms
as Perl itself.
AVAILABILITY:
>From CPAN, in directory
http://www.cpan.org/modules/by-authors/id/N/NE/NEDKONZ/
or
ftp://ftp.cpan.org/pub/CPAN/modules/by-authors/id/N/NE/NEDKONZ/
as Archive-Zip-1.09.tar.gz
------------------------------
Date: 30 Nov 2003 10:09:58 -0800
From: skendric@fhcrc.org (Stuart Kendrick)
Subject: binding ICMP to a specific IP address
Message-Id: <62dbf7f1.0311301009.5e72010c@posting.google.com>
hi,
i'd like to run a number of ICMP intensive scripts from a single box.
in my experience, this is problematic ... ICMP doesn't support ports
the way TCP and UDP do, so the IP stack doesn't know to which process
to return the ICMP Echo Reply ... so process A can receive a response
to a ping which process B emitted ... neither process enjoys this ...
nor does the operator.
typically, /usr/sbin/ping supports the "-I" parameter, which allows it
to bind to a specified IP address ... that way, i can configure the box
with multiple IP addresses, bind each process' /usr/sbin/ping instance
to a different IP address ... and avoid stomping on myself.
but fping doesn't support the "-I" parameter. and i really like a number
of fping's features.
argh.
ok, so i can rewrite fping in Perl ... the Net::Ping module ships with
example code. and Net::Ping supports a 'bind' parameter, which allows
lets me specify the source IP address for the ICMP packet. but then,
i have to run my scripts as root or at least as setuid root ... neither
of which thrills me.
Net::Ping::External doesn't require root access to run, as it uses the
OS's ping binary. But ... it doesn't yet support binding to different
IP addresses (presumably, the "-I" parameter varies enough between OSes
that this is hard to support).
i think i'm stuck. i think i need more hardware -- one box per
ping-intensive app.
does anyone know of way around this?
--sk
Stuart Kendrick
FHCRC
------------------------------
Date: Sun, 30 Nov 2003 18:23:01 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: binding ICMP to a specific IP address
Message-Id: <bqdci5$2vs$1@wisteria.csv.warwick.ac.uk>
skendric@fhcrc.org (Stuart Kendrick) wrote:
> ok, so i can rewrite fping in Perl ... the Net::Ping module ships with
> example code. and Net::Ping supports a 'bind' parameter, which allows
> lets me specify the source IP address for the ICMP packet. but then,
> i have to run my scripts as root or at least as setuid root ... neither
> of which thrills me.
At least on my machine, /bin/ping is setuid root. I am fairly sure it
has to be to send ICMP packets. If you are saying that you'd rather
run someone else's (peer-reviewed) code as root than write your own
(which is fair enough)...
> Net::Ping::External doesn't require root access to run, as it uses the
> OS's ping binary. But ... it doesn't yet support binding to different
> IP addresses (presumably, the "-I" parameter varies enough between OSes
> that this is hard to support).
...then write your own wrapper around ping, probably based on
Net::Ping::External. But fping features like round-robin pinging of
hosts until they reply will be 'nigh-on impossible to emulate:
obviously, the same applies if you use Net::Ping::External.
Alternatively, you could use Net::Ping's UDP- or TCP-ping feature, which
doesn't have either problem.
Ben
--
"The Earth is degenerating these days. Bribery and corruption abound.
Children no longer mind their parents, every man wants to write a book,
and it is evident that the end of the world is fast approaching."
-Assyrian stone tablet, c.2800 BC ben@morrow.me.uk
------------------------------
Date: Sun, 30 Nov 2003 17:03:02 +0100
From: Jaap Karssenberg <j.g.karssenberg@student.utwente.nl>
Subject: character encodings
Message-Id: <20031130170302.3207d13c.j.g.karssenberg@student.utwente.nl>
I have a script that should read files utf8 compliant, so I used
binmode(FILE, ':utf8'). But now it appears some users have latin2
encoded files, causing some regexes to throw warnings about malformed
utf8 chars. Is there a way to detect the character encoding and DWIM ? I
would hate to have to tell my users they should convert everything to
utf8 first.
--
) ( Jaap Karssenberg || Pardus [Larus] | |0| |
: : http://pardus-larus.student.utwente.nl/~pardus | | |0|
) \ / ( |0|0|0|
",.*'*.," Proud owner of "Perl6 Essentials" 1st edition :)
------------------------------
Date: Sun, 30 Nov 2003 16:52:46 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: character encodings
Message-Id: <yfpyb.33350$ZV6.7121@nwrddc02.gnilink.net>
Jaap Karssenberg wrote:
> I have a script that should read files utf8 compliant, so I used
> binmode(FILE, ':utf8'). But now it appears some users have latin2
> encoded files, causing some regexes to throw warnings about malformed
> utf8 chars. Is there a way to detect the character encoding and DWIM
You don't tell us what kind fo files those are.
For e.g. HTML or XML the meta charset header resp. the encoding attribute
should tell you what encoding to expect.
Just scan for it and evaluate the rest of the file accordingly.
jue
------------------------------
Date: Sun, 30 Nov 2003 19:46:05 +0100
From: Jaap Karssenberg <j.g.karssenberg@student.utwente.nl>
Subject: Re: character encodings
Message-Id: <20031130194605.606514ab.j.g.karssenberg@student.utwente.nl>
On Sun, 30 Nov 2003 16:52:46 GMT J=FCrgen Exner wrote:
: You don't tell us what kind fo files those are.
: For e.g. HTML or XML the meta charset header resp. the encoding
: attribute should tell you what encoding to expect.
: Just scan for it and evaluate the rest of the file accordingly.
Can be all kinds of files, the script is there to determine what they
are. In general the files have neither meta data attached to them or
headers with meta data.
--=20
) ( Jaap Karssenberg || Pardus [Larus] | |0| |
: : http://pardus-larus.student.utwente.nl/~pardus | | |0|
) \ / ( |0|0|0|
",.*'*.," Proud owner of "Perl6 Essentials" 1st edition :) =20
------------------------------
Date: Sun, 30 Nov 2003 18:47:29 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: character encodings
Message-Id: <Pine.LNX.4.53.0311301835050.16904@ppepc56.ph.gla.ac.uk>
On Sun, 30 Nov 2003, Jürgen Exner wrote:
> For e.g. HTML or XML the meta charset header resp. the encoding attribute
> should tell you what encoding to expect.
Maybe. Depends how the files got there. For HTTP transactions it's
legal (and often preferable) to supply the character coding on the
actual HTTP content-type header, and to make no mention of it inside
the actual body of the content. However, the O.P speaks of "files",
so presumably you're right, and the HTTP transaction issue is outside
this particular problem domain. But there's still the BOM option to
keep in mind!
> Just scan for it and evaluate the rest of the file accordingly.
But you can't scan it without reading it, and you can't read it
without opening it; so you'd have to open it provisionally with *some*
mode, scan for the stuff that you have described - and then maybe
re-open it with a different mode?
OTOH, if one opens it in raw mode, and scans it in a way which can
accommodate itself to different encodings, then, when the relevant
encoding information has been found, the data can be piped through the
appropriate encoding layers explicitly.
There's a lot of options, and I'm not sure of the practical
implications of choosing one or another. If the data is to be
processed by an appropriate HTML or XML module, maybe that module can
adapt to different data encodings as read in raw mode?
What I think it comes down to is that it would definitely be a mistake
to open the file with a utf8 IO layer without being sure that it's
utf-8-encoded, due to the errors that will inevitably result if it
isn't.
hope this helps a bit.
------------------------------
Date: Sun, 30 Nov 2003 10:04:47 -0500
From: "Domenico Discepola" <joeminga@yahoo.com>
Subject: Re: config::inifiles and retrieval of delimiter
Message-Id: <NJnyb.13283$Ac1.83978@weber.videotron.net>
> Sure. Just eval it in an interpolated string, like [untested]:
>
> my $delimiter=eval "\"$my_iniinput->val('GLOBAL','delimiter')\"";
>
Thank you for the code - I was able to use it to come up with this example
as well:
#!perl
use strict;
use warnings;
my $a = '\n';
my $b = eval "\"$a\"";
print "[$b]\n";
########################
Output:
[
]
------------------------------
Date: Fri, 28 Nov 2003 02:35:28 GMT
From: Steven W McDougall <swmcd@TheWorld.com>
Subject: Convert::yEnc 1.01
Message-Id: <Hp6EDE.xIC@zorch.sf-bay.org>
Convert::yEnc 1.01 has been released to CPAN.
A yEnc decoder, with database of file parts
Convert::yEnc decodes yEncoded files and writes them to disk. File
parts are saved to a temporary directory; when all parts of a file
have been received, the completed file is moved to its final location.
Convert::yEnc maintains a database of partially received files, called
the RC database. The RC database is loaded from disk when a
Convert::yEnc object is created, and saved to disk when the object is
DESTROY'd.
INSTALLATION
To install this module type the following:
perl Makefile.PL
make
make test
make install
DEPENDENCIES
This module requires these other modules and libraries:
IO::File
Set::IntSpan
Send suggestions, bugs, etc. to swmcd@world.std.com
ACKNOWLEDGMENTS
Laurent Caprani <laurent.caprani@laposte.net>
Jason Hudgins <thanatos@incantations.net>
Eric Young <eay@pobox.com>
COPYRIGHT AND LICENCE
Copyright (C) 2002-2003 Steven W McDougall
This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.
Revision history for Perl extension Convert::yEnc
1.01 2003 Nov 26
Convert::yEnc
- fixed _complete()
- use warnings
Convert::yEnc::Decode.pm
- go faster
- use warnings
Convert::yEnc::RC.pm
- use warnings
Convert::yEnc::Entry.pm
- use warnings
1.00 2002 Nov 13
Initial version
TODO
1. XS implementation of Convert::yEnc::Decoder::_line
2. CRCs
3. Encoding
------------------------------
Date: Sun, 30 Nov 2003 15:48:56 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: DBI error handling
Message-Id: <bqd3h8$p7f$1@wisteria.csv.warwick.ac.uk>
Tore Aursand <tore@aursand.no> wrote:
> Really? Consider this code;
>
> my $sth = $dbh->prepare( 'SELECT * FORM user' ); # typo 'FORM'
> if ( $sth->execute() ) {
> # Works!
> }
> else {
> # Doesn't work!
> }
> $sth->finish();
>
> I think this is cleaner, and I also suspect it to be faster than using
> 'eval'.
Whether or not it is cleaner depends on the application. Some
applications benefit from not having to check the return of every
statement, instead being able to put all the error handling in one
place.
> Doesn't 'eval' spawn of a "mini-Perl" process, and doesn't it
> take some time to run?
As someone else said, you are confusing eval "" with eval {}. Yes,
this is something of a conflation of ideas: the concept of catching
die() is quite different from run-time evaluation of code; but there
we go.
Ben
--
"If a book is worth reading when you are six, * ben@morrow.me.uk
it is worth reading when you are sixty." - C.S.Lewis
------------------------------
Date: Sun, 30 Nov 2003 17:53:04 +0100
From: Jo Oberman <johanoberm@gmx.de>
Subject: Deleting tmp-files of CGI.pm upload()
Message-Id: <157ksvsg7o0msp8ohqn2mkj3dcdclp1uco@4ax.com>
Hello,
I'm using CGI.pm to make some file uploads to the web-server.
It works great, but the problem is that I'm not able to delete
the temp--files that are created during upload.
Here is the code that makes the problem:
1) my $query = new CGI();
2) my $fh = $query->upload('FileInputName');
3) File::Copy::copy(*{$fh}, "../myDir/myFile.txt") or die "Can't copy uploaded picture '$fh': $!"; # that works
4) unlink(*{$fh}) or die "Can't remove uploaded temp file: $!"; # that does't work
In line 4) the unlink always failed with the message "No such file or directory".
(But the file cgitempXXX in temp-directory is still there!)
If I change line 3) into "File::Copy::move(.....)" I get the message "no permission ...".
What is the right way to move (== copy and delete) the temp-upload-file to
my own destination ???
Using currently for testing: perl 5.6.1 CGI.pm V2.93 on an Windows XP - Box
Thanks for helping
Jo
------------------------------
Date: 30 Nov 2003 10:17:49 -0800
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)
Subject: Re: Deleting tmp-files of CGI.pm upload()
Message-Id: <3fca344d@news.victoria.tc.ca>
Jo Oberman (johanoberm@gmx.de) wrote:
: Hello,
: I'm using CGI.pm to make some file uploads to the web-server.
: It works great, but the problem is that I'm not able to delete
: the temp--files that are created during upload.
: Here is the code that makes the problem:
: 1) my $query = new CGI();
: 2) my $fh = $query->upload('FileInputName');
: 3) File::Copy::copy(*{$fh}, "../myDir/myFile.txt") or die "Can't copy uploaded picture '$fh': $!"; # that works
: 4) unlink(*{$fh}) or die "Can't remove uploaded temp file: $!";
I would always include the file name in the error message, so here I might
try
die "Can't remove uploaded temp file: $!, ",*{$fh};
to see what it is was I was not able to delete.
Also, I wonder (and by this I mean I do not know and would look it up), I
wonder if you need to delete the CGI temp file at all? I think the module
could delete the file while it has an open file handle and the data would
not disappear until the last file handle is closed (even though the file
is no longer "visible" to directory listings). (But look it up).
------------------------------
Date: Sun, 30 Nov 2003 18:24:57 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Deleting tmp-files of CGI.pm upload()
Message-Id: <bqdclp$2vs$2@wisteria.csv.warwick.ac.uk>
yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones) wrote:
> : 4) unlink(*{$fh}) or die "Can't remove uploaded temp file: $!";
>
> I would always include the file name in the error message, so here I might
> try
>
> die "Can't remove uploaded temp file: $!, ",*{$fh};
Unless I am very much mistaken, that is not a filename at all but a
filehandle. This will be why you can't unlink it: perl will be
attempting to unlink the stringification of the filehandle, which is
unlikely to be terribly successful.
Ben
--
If I were a butterfly I'd live for a day, / I would be free, just blowing away.
This cruel country has driven me down / Teased me and lied, teased me and lied.
I've only sad stories to tell to this town: / My dreams have withered and died.
ben@morrow.me.uk <=>=<=>=<=>=<=>=<=>=<=>=<=>=<=>=<=>=<=>=<=> (Kate Rusby)
------------------------------
Date: 30 Nov 2003 10:46:33 -0800
From: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones)
Subject: Re: Deleting tmp-files of CGI.pm upload()
Message-Id: <3fca3b09@news.victoria.tc.ca>
Ben Morrow (usenet@morrow.me.uk) wrote:
: yf110@vtn1.victoria.tc.ca (Malcolm Dew-Jones) wrote:
: > : 4) unlink(*{$fh}) or die "Can't remove uploaded temp file: $!";
: >
: > I would always include the file name in the error message, so here I might
: > try
: >
: > die "Can't remove uploaded temp file: $!, ",*{$fh};
: Unless I am very much mistaken, that is not a filename at all but a
: filehandle. This will be why you can't unlink it: perl will be
: attempting to unlink the stringification of the filehandle, which is
: unlikely to be terribly successful.
: Ben
Exactly. If he had included the value he was trying to delete in the error
message I think he would have quickly discovered that.
------------------------------
Date: Sun, 30 Nov 2003 11:24:15 -0500
From: "Bazil" <Admin@goMonitor.com>
Subject: Re: Memory Allocation Error when to fetching BLOB field from MS-SQL server Table
Message-Id: <KQoyb.2157$zf2.81946@news20.bellglobal.com>
- There are no trouble fetching non blob fields, (Text ,numeric etc.)
-Inserted a 3 character text into Blob Field, OK
- Fetch a 3 Characte Blob text "ABC" failed as well
It looks like trying to allocate -1 byte to image field and it failes!!!
SQL ERR on: Select viewcontent from NewProfile where ID='AA' and
CUSTID='BEHZAD' SQL-Err:[911] [2] [0] "Could not allocate enough memory (-1
bytes) for column 1.
"
"William Herrera" <posting.account@lynxview.com> wrote in message
news:3fc954b6.21550677@news2.news.adelphia.net...
> On Sat, 29 Nov 2003 20:33:04 -0500, "Bazil" <Admin@goMonitor.com> wrote:
>
> >If anyone has experience in fetching a Blob field on MS-SQL(7) please
have a
> >look at this.
> >
> >I am trying to fetch a Blob column (Image) from a MS-SQL(7) table.
> >The select terminates with and error:
> >"Could not allocate enough memory (-1 bytes) for column 1."
> > it dies on line 14.
> >
> >Thanks for any suggestion.
> >
> >9 $SqlString = " Select viewcontent from NewProfile where ID='Prof2'
";
> >10 if(($dbh->Sql( $SqlString )))
> >11 {
> >12 $ErrMsg = 'SQL-Err:'.$dbh->Error();
> >13 print "SQL ERR on: $SqlString $ErrMs
> >14 die
> >15 };
> >16 $dbh->FetchRow();
> >17 {
> >18 undef %Data;
> >19 %Data = $dbh->DataHash();
> >10 $FldContent=$Data{$_[1]};
>
> Suggestion: can you fetch a small, non-blob data entry form the same
database?
> If you can, then see how big of a blob you can fetch without error--start
with
> a blob one byte in size.
>
> Can you add a line to the database with the test data oulined above?
>
> ---
> Use the domain skylightview (dot) com for the reply address instead.
------------------------------
Date: Sun, 30 Nov 2003 14:27:56 GMT
From: Mike Flannigan <mikeflan@earthlink.net>
Subject: Re: Newsgroup Searching Program
Message-Id: <3FC9FF2B.6F772A4E@earthlink.net>
Gerard Lanois wrote:
> So far, so good.
>
> Does your news server require an account and password? If so, you'll
> want to add lines that look like this:
>
> my $account = 'myaccount';
> my $password = 'secret';
>
> $nntp->authinfo($account, $password)
> or die "ERROR: Net::NNTP->authinfo() failed.\n";
>
Wow, that is soooo cool. I just put the 4 lines above
(modified) and it worked. It printed the oldest message
in the list (481818). Now I've got something to work
with.
I happen to have the book "Network Programming with
Perl". I'll have to dig that out to pursue the other stuff
you mentioned.
Thanks for everyone's help. I really appreciate it.
Fun stuff to do now :-)
Mike
------------------------------
Date: Sun, 30 Nov 2003 18:54:03 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: Perl unicode and :crlf, was Re: regexp: \x0a => \x0d\x0a
Message-Id: <Pine.LNX.4.53.0311301849060.16904@ppepc56.ph.gla.ac.uk>
On Sat, 29 Nov 2003, Ben Morrow wrote:
> "Alan J. Flavell" <flavell@ph.gla.ac.uk> wrote:
> > Incidentally I've found that for utf-8 data the "od -t x1" format is
> > handy, rather than "od -x".
>
> Yes, I found that too. -x is good for little-endian stuff, though.
Agreed.
> > > I would seriously consider not using :crlf at all, but instead writing
> > > a :nl layer that maps any of \n, \r, \r\n to \n on input and any of
> > > \n, \r, \r\n to \r\n on output... seems to me that'd be more use, in
> > > general. I guess it would probably be slower.
>
> http://morrow.me.uk/PerlIO-nline-0.01.tar.gz
>
> > If it was part of the infrastructure, I doubt that the difference in
> > speed would be noticeable.
Thanks for the interesting posting! Just to make my meaning clear, I
meant "I doubt that the difference would be noticeable within the
scope of a realistic application". The benchmarking is interesting,
all the same.
Your approach is clearly more versatile. But the :crlf layer ought to
do what it says on the tin, shouldn't it? - and from the previous
discussion, it rather looks as if it isn't doing. Or else I was using
it wrong, but I tried several interpretations - and all the others
seemed to be even worse.
cheers
------------------------------
Date: 30 Nov 2003 08:20:50 -0800
From: nilendu_das@persistent.co.in (Nilendu)
Subject: Problem installing through PPM
Message-Id: <3e9d326e.0311300820.597e65ac@posting.google.com>
Hello,
I have to use DateTime::Format::Epoch moudle to convert any given time
to its corresponding Epoch value. But when i search for the module
using ppm from active perl 5.6.1 it shows no match for
Date:Time::Epoch
what could be the possible reasons
Thanks and regards,
Nilendu
------------------------------
Date: Sun, 30 Nov 2003 09:54:34 -0500
From: Chris Mattern <syscjm@gwu.edu>
Subject: Re: Reading Dates from Excel-file
Message-Id: <3FCA04AA.8070004@gwu.edu>
bruno wrote:
>>A "quick fix" is to test to
>>see if $item is a reference, and, if it is, assume it is a reference to
>>a Win32::OLE::Variant Date object, and stringify the date. This can be
>>done with:
>>
>> use Win32::OLE::NLS qw(:LOCALE :DATE); #to get the constant
>> $line.=(ref($item)?$item->Date(DATE_LONGDATE):$item)."\t";
>
>
>
> Thanks, got it.
>
> BTW, for some reason I get the answers via mail hours before they
> appear on the board.
Scarcely surprising. Mail gets sent directly to your service's SMTP
server, while news has to get passed from server to server along the
NNTP backbone until it gets to your news server. It's the difference
between point-to-point and scalable broadcast.
Chris Mattern
------------------------------
Date: Sun, 30 Nov 2003 14:02:49 GMT
From: James Willmore <jwillmore@remove.adelphia.net>
Subject: Re: trouble with DBI/CGI
Message-Id: <20031130090247.117255a8.jwillmore@remove.adelphia.net>
On Sun, 30 Nov 2003 05:04:50 -0700
Ron Reidy <r_reidy@comcast.net> wrote:
> The problem is malformed header. Check the CGI docs and look in the
> web browser's error log.
This is part of the problem ....
He's not checking the connection success/failure. So, for
some reason, the connection is failing while running the script
through the web server.
>
> David Morel wrote:
> > Consider the following program:
> >
> > #!/usr/local/bin/perl -w
> > use strict;
> > use DBI;
> > use CGI ':standard';
> >
> > print "Content-type: text/plain\n\n";
> > print "abc\n";
> > my $dbh = DBI->connect("dbi:Oracle:ORCL", "username", "password");
Change to:
my $dbh = DBI->connect("dbi:Oracle:ORCL", "username", "password")
or die "Can't connect: ", $DBI::errstr,"\n";
This will cause the script to fail if it can't connect to the
database. Be careful with the above code. Don't use it in a
production environment. If memory serves - Oracle will report the
username and password in the error message. So, just take the
'$DBI::errstr' portion out if running this code in production.
HTH
--
Jim
Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.
a fortune quote ...
The idea is to die young as late as possible. -- Ashley Montagu
------------------------------
Date: 30 Nov 2003 07:06:53 -0800
From: genericax@hotmail.com (Sara)
Subject: Re: trouble with DBI/CGI
Message-Id: <776e0325.0311300706.ebebe70@posting.google.com>
altalingua@hotmail.com (David Morel) wrote in message news:<60c4a7b1.0311292116.670c439f@posting.google.com>...
> Hi,
>
> I am having trouble combining DBI and CGI.
>
> Consider the following program:
>
> #!/usr/local/bin/perl -w
> use strict;
> use DBI;
> use CGI ':standard';
>
> print "Content-type: text/plain\n\n";
> print "abc\n";
> my $dbh = DBI->connect("dbi:Oracle:ORCL", "username", "password");
> print "123\n";
>
>
> When I run the above program from a web browser, I get the output:
> abc
>
> When I run the above program from the command line, I get the output:
> abc
> 123
>
> In other words, it seems that when I run the script from the web it
> stops immediately after it creates the database handle... but works
> properly when run from the command line.
>
> What gives?
>
> Thank you,
> David Morel
Put this on top, make sure you have RW access to cgi.log in the cgidir
(or put it somewhere safer if you need to..)
use strict;
use CGI::Carp qw(carpout);
use CGI::Carp qw(fatalsToBrowser);
open LOG, ">./cgi.log";
carpout(*LOG);
I've found with DBI, many errors DON'T get to the browser, but the SQL
fails. In those cases, the log file always captures them. This is
particularly true for incorrect SQL statements.
good luck!
G
------------------------------
Date: Sun, 30 Nov 2003 16:07:00 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: trouble with DBI/CGI
Message-Id: <Pine.LNX.4.53.0311301556210.16904@ppepc56.ph.gla.ac.uk>
On Sun, 30 Nov 2003, Ron Reidy helped to prove what we all suspected
about TOFU-posters:
> The problem is malformed header.
The original poster reported:
| When I run the above program from a web browser, I get the output:
| abc
How do you suppose he'd have got that, if he had a malformed header?
> Check the CGI docs
No bad idea as a general rule, but speaking for myself, I think I'm
sufficiently familiar with them to know that they won't throw any
light on this particular issue.
> and look in the web browser's error log.
OK, you got one bit right. But when testing, it might be better to
arrange for the program to report errors to the browser. Others have
already supplied those details (i.e testing for success of calls,
using CGI::Carp options etc.): after you've revised your knowledge of
usenet posting netiquette (the group's posting guidelines have useful
advice on the topic), you might want to get up to speed by reading the
other postings on the thread.
You then quoted:
> David Morel wrote:
[...]
> > print "Content-type: text/plain\n\n";
> > print "abc\n";
[...]
> > When I run the above program from a web browser, I get the output:
> > abc
Indeed he did write that, but like many typical TOFU-posters, you see
to have blurted out an answer without grasping the meaning of what you
are so comprehensively quoting.
good luck.
------------------------------
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.
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 5875
***************************************
