[26000] in Perl-Users-Digest
Perl-Users Digest, Issue: 8219 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jul 1 14:05:35 2005
Date: Fri, 1 Jul 2005 11:05:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 1 Jul 2005 Volume: 10 Number: 8219
Today's topics:
"Variable ... is not imported..." using an imported v (Volker Nicolai)
Re: "Variable ... is not imported..." using an import <pilkowsk@informatik.uni-marburg.de>
Re: "Variable ... is not imported..." using an import <nobull@mail.com>
DBD::Sybase / DBD::ODBC + FreeTDS woes - placeholders a <richard@zync.co.uk>
Re: problem in passing parameters in function defined i <vikrantREMOVE@DELETEsaysnetsoftDDDD.com>
Validating XML data <vikrantREMOVE@DELETEsaysnetsoftDDDD.com>
Re: Validating XML data <scobloke2@infotop.co.uk>
Re: Validating XML data <vikrantREMOVE@DELETEsaysnetsoftDDDD.com>
Re: Validating XML data <glex_no-spam@qwest-spam-no.invalid>
Re: Validating XML data <sherm@dot-app.org>
Re: weird behavior with open and pipe <moritz.karbach@desy.de>
Re: weird behavior with open and pipe <thepoet_nospam@arcor.de>
Re: weird behavior with open and pipe (Anno Siegel)
Re: weird behavior with open and pipe <vek@station02.ohout.pharmapartners.nl>
Re: weird behavior with open and pipe <vek@station02.ohout.pharmapartners.nl>
Re: weird behavior with open and pipe <moritz.karbach@desy.de>
Re: weird behavior with open and pipe <nobull@mail.com>
Re: weird behavior with open and pipe <thepoet_nospam@arcor.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 1 Jul 2005 07:04:28 -0700
From: vnick@freenet.de (Volker Nicolai)
Subject: "Variable ... is not imported..." using an imported variable from a module
Message-Id: <de7655a5.0507010604.2c5ab935@posting.google.com>
Hi,
I have read a lot about use strict and the visibility of variables
but still can not understand why my following problem occurs:
I have this small script:
-------------------------------------------
#!/usr/local/bin/perl
#use strict; # _1_
use import_pack;
# use vars qw($p_hash); # _2_
# *p_hash = \%main::p_hash; # _3_
# print "P_HASH: $::p_hash{x} , $::p_hash{y}\n"; # _4_
print "P_HASH: $p_hash{x} , $p_hash{y}\n"; # _5_
-------------------------------------------
and the module import_pack.pm:
-------------------------------------------
#!/usr/local/bin/perl
use Exporter;
@ISA = qw(Exporter);
@EXPORT = qw(%p_hash);
%p_hash = (
x => 123,
y => 888,
);
1;
-------------------------------------------
If I run it without use stricts it is fine.
But if I use strict (_1_) then I need line _4_* instead of _5_,
otherwise I get:
Variable "%p_hash" is not imported at import_test.pl line 9
Neither the 'announcement' of %p_hash with line _2_* nor the typeglob
line _3_* helps and I don't have any idea why. I thought the typeglob must be
pretty much the same as using the full var name (with package) in the
print statement.
So where is the crux?
(* uncommented :-)
Thanks for helping!
Volker
------------------------------
Date: Fri, 1 Jul 2005 18:24:13 +0200
From: Fabian Pilkowski <pilkowsk@informatik.uni-marburg.de>
Subject: Re: "Variable ... is not imported..." using an imported variable from a module
Message-Id: <3il8viFm54j0U1@individual.net>
* Volker Nicolai schrieb:
>
> I have read a lot about use strict and the visibility of variables
> but still can not understand why my following problem occurs:
>
> I have this small script:
> -------------------------------------------
> #!/usr/local/bin/perl
> #use strict;
> use import_pack;
> print "P_HASH: $p_hash{x} , $p_hash{y}\n";
> -------------------------------------------
>
> and the module import_pack.pm:
> -------------------------------------------
> #!/usr/local/bin/perl
> use Exporter;
> @ISA = qw(Exporter);
> @EXPORT = qw(%p_hash);
> %p_hash = (
> x => 123,
> y => 888,
> );
> 1;
> -------------------------------------------
Well, you know you should use strict. But please do it in your modules
too. After doing so, you have to declare your vars used in your module.
But remember to declare each var you want to export with our() instead
of my() -- better yet: each var you want to access from outside. Btw, I
don't see a declaration of your package in that package. I'd write it as
something like:
#!/usr/local/bin/perl -w
package import_pack;
use strict;
use Exporter;
our @ISA = qw(Exporter);
our @EXPORT = qw(%p_hash);
our %p_hash = (
x => 123,
y => 888,
);
1;
__END__
>
> If I run it without use stricts it is fine.
> But if I use strict [...] I get:
> Variable "%p_hash" is not imported at [...]
> So where is the crux?
I suggest to fix your module first. To understand the error message you
have to know what use() is doing (see `perldoc -f use`). In short, it
require()s the file and tries to call import() from the package. The
latter is your problem. It's not possible to call import_pack->import()
since there is no package called "import_pack". It is just part of the
file's name and that is not what Perl uses as the default package name.
The default package is called "main", and all you have done in the file
"import_pack.pm" is done in package "main" though.
Your script is running fine with stricts if you only add the declaration
of the package's name in your package file. But familiarize yourself
with using strict in your modules too. My example above shows you what
you need for that. Btw, our() creates exactly the same type of globals
as you would do without any declaration under "no strict", but it has
the same scoping rules as a declaration with my(). Please read `perldoc
-f our` for details.
regards,
fabian
------------------------------
Date: Fri, 01 Jul 2005 18:28:03 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: "Variable ... is not imported..." using an imported variable from a module
Message-Id: <da3uf3$ije$2@redhat2.bham.ac.uk>
Fabian Pilkowski wrote:
[ In the context of an example .pm file ]
> #!/usr/local/bin/perl -w
There's no shebang line in a module.
> package import_pack;
> use strict;
You forgot use warnings. Probably because you thought the shebang line
would do it.
------------------------------
Date: Fri, 01 Jul 2005 15:55:02 +0100
From: Richard Gration <richard@zync.co.uk>
Subject: DBD::Sybase / DBD::ODBC + FreeTDS woes - placeholders and implicit datatype conversions
Message-Id: <pan.2005.07.01.14.54.26.808300@zync.co.uk>
Hi All,
I'm trying to issue SQL queries, which contain placeholders, from a
Gentoo Linux desktop to a Redhat Linux 7.1 server running Sybase ASE
11.0.3, using freetds (and unixODBC) and DBI. It all works well with a
variety of CLI clients: sqsh, tsql (freetds) and isql (unixODBC). The
problem comes when using DBI and placeholders.
freetds does not support placeholders at all, in any TDS version it
implements, so that kiboshes DBD::Sybase. They suggest using their ODBC
lib and DBD::ODBC. Everything is OK until trying to use a placeholder for
a numeric argument. Then the dreaded
========
Implicit conversion from datatype 'VARCHAR' to 'NUMERIC' is not allowed.
Use the CONVERT function to run this query.
========
error message appears. I've tried all sorts of things to get round this
but nothing works for me. I know that there is a little(!) magic inside
perl for allowing scalar values to be both strings and numbers as needed
and I wonder if this is the issue here.
Please, please, please does anybody know how I can solve this problem? I
have googled and peered into source code and nothing I've tried works.
Thanks for reading
Rich
------------------------------
Date: Fri, 01 Jul 2005 20:18:31 +0530
From: Vikrant <vikrantREMOVE@DELETEsaysnetsoftDDDD.com>
Subject: Re: problem in passing parameters in function defined in perl module
Message-Id: <da3l64$fch$1@domitilla.aioe.org>
Sherm Pendley wrote:
>
> He's probably accustomed to C, Java, Pascal, or some other language where
> arguments are named and their names declared with the function prototype. For
> instance, in C:
>
> void Configure(int ddd) {
> ...
> }
Actually yes, I am accustomed to C style coding, and that is what was
baffling me. Thanks all for your help once again.
Vikrant
------------------------------
Date: Fri, 01 Jul 2005 19:51:45 +0530
From: Vikrant <vikrantREMOVE@DELETEsaysnetsoftDDDD.com>
Subject: Validating XML data
Message-Id: <da3jk4$e6a$1@domitilla.aioe.org>
Hi
I am receiving XML data over a TCP socket. How do I validate the
incoming data as a valid XML ? I would prefer some function which simply
returns true or false after the validation procedure.
I have already tried working with "XML::LibXML::Document" is_valid
function, but somehow could not make it work. I am not very proficient
in Perl, so would request a easy to follow example.
Thanks
Vikrant
------------------------------
Date: Fri, 1 Jul 2005 15:42:36 +0000 (UTC)
From: Ian Wilson <scobloke2@infotop.co.uk>
Subject: Re: Validating XML data
Message-Id: <da3o9b$a9a$1@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>
Vikrant wrote:
> Hi
>
> I am receiving XML data over a TCP socket. How do I validate the
> incoming data as a valid XML ? I would prefer some function which simply
> returns true or false after the validation procedure.
>
> I have already tried working with "XML::LibXML::Document" is_valid
> function, but somehow could not make it work. I am not very proficient
> in Perl, so would request a easy to follow example.
The documentation (which I assume you have read?) says something like:
if ($dom->is_valid($dtd)) {
print "document is valid!\n";
} else {
print "document is not valid.\n";
}
Maybe you should first try this in a small test script that reads some
simple in-line XML. If you can't get it to work, post your test script.
------------------------------
Date: Fri, 01 Jul 2005 22:00:11 +0530
From: Vikrant <vikrantREMOVE@DELETEsaysnetsoftDDDD.com>
Subject: Re: Validating XML data
Message-Id: <da3r4u$m78$1@domitilla.aioe.org>
Ian Wilson wrote:
>
> The documentation (which I assume you have read?) says something like:
>
> if ($dom->is_valid($dtd)) {
> print "document is valid!\n";
> } else {
> print "document is not valid.\n";
> }
>
> Maybe you should first try this in a small test script that reads some
> simple in-line XML. If you can't get it to work, post your test script.
Sorry, I was not clear earlier. This is the code I am trying to use:
#!usr/bin/perl
use strict;
use XML::LibXML();
$sXML = "<?xml version='1.0' ?>
<ping_monitor>
<monitor_ip>10.0.0.4</monitor_ip>
<monitor_ip>10.0.0.2</monitor_ip>
<ping_monitor>";
******************************************************************
Now if I need to check the xml validity in $sXML what do I do? I tried
loading the variable in a dom object, but it immediately throws an error.
If possible, I would like a simple function which simply returns either
true or false after validation
Vikrant
------------------------------
Date: Fri, 01 Jul 2005 11:53:17 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Validating XML data
Message-Id: <2yexe.16$br4.319@news.uswest.net>
Vikrant wrote:
> Ian Wilson wrote:
>
>>
>> The documentation (which I assume you have read?) says something like:
>>
>> if ($dom->is_valid($dtd)) {
>> print "document is valid!\n";
>> } else {
>> print "document is not valid.\n";
>> }
>>
>> Maybe you should first try this in a small test script that reads some
>> simple in-line XML. If you can't get it to work, post your test script.
>
>
> Sorry, I was not clear earlier. This is the code I am trying to use:
>
> #!usr/bin/perl
>
> use strict;
> use XML::LibXML();
>
> $sXML = "<?xml version='1.0' ?>
> <ping_monitor>
> <monitor_ip>10.0.0.4</monitor_ip>
> <monitor_ip>10.0.0.2</monitor_ip>
> <ping_monitor>";
>
> ******************************************************************
Hu.. I get:
Global symbol "$sXML" requires explicit package name at ./xmlscript.pl
line 5.
Execution of ./xmlscript.pl aborted due to compilation errors.
First, make sure your perl is valid.. :-)
> Now if I need to check the xml validity in $sXML what do I do? I tried
> loading the variable in a dom object, but it immediately throws an error.
What's the error?
There's obviously a problem with how you're doing that. Post your
*actual* code.
>
> If possible, I would like a simple function which simply returns either
> true or false after validation
The is_valid *method* does just that.
------------------------------
Date: Fri, 01 Jul 2005 12:26:04 -0400
From: Sherm Pendley <sherm@dot-app.org>
Subject: Re: Validating XML data
Message-Id: <87u0jeh4rn.fsf@dot-app.org>
Vikrant <vikrantREMOVE@DELETEsaysnetsoftDDDD.com> writes:
> $sXML = "<?xml version='1.0' ?>
> <ping_monitor>
> <monitor_ip>10.0.0.4</monitor_ip>
> <monitor_ip>10.0.0.2</monitor_ip>
> <ping_monitor>";
>
> ******************************************************************
>
> Now if I need to check the xml validity in $sXML what do I do?
Well, for one thing you need to understand what "valid" means in context
of XML. "Valid" XML conforms to a specified DTD - but you haven't specified
a DTD in this example, so by definition it cannot be valid.
sherm--
--
Due to the amount of unreadable gibberish being posted from Google Groups,
I seldom read messages posted from there.
Cocoa/Perl: http://camelbones.sf.net Hire Me: http://www.dot-app.org
------------------------------
Date: Fri, 01 Jul 2005 13:00:10 +0200
From: Moritz Karbach <moritz.karbach@desy.de>
Subject: Re: weird behavior with open and pipe
Message-Id: <da37nr$ib4l$1@claire.desy.de>
Hi Anno,
> Buffering. The output is still in a buffer when the program gets killed,
> so the data is lost. At least, that's consistent with what you're
> seeing.
Well the thing is, whem I'm running the executable directly on the shell, it
immediately prints out some lines, then starts "hard working" without any
output.
I'm killing it during the "hard working" phase (in fact the watchdog of my
Command class kills the whole process group, so any of the subprocesses
launched by my shell fake binary gets killed as well).
If it was buffering (steered from within the binary), I don't understand why
I see the output lines on the shell directly, but in the Perl program I
don't.
Cheers,
- Moritz
------------------------------
Date: Fri, 01 Jul 2005 13:59:12 +0200
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: weird behavior with open and pipe
Message-Id: <42c53012$0$22763$9b4e6d93@newsread2.arcor-online.net>
Moritz Karbach schrieb:
> Well the thing is, whem I'm running the executable directly on the shell, it
> immediately prints out some lines, then starts "hard working" without any
> output.
>
> I'm killing it during the "hard working" phase (in fact the watchdog of my
> Command class kills the whole process group, so any of the subprocesses
> launched by my shell fake binary gets killed as well).
>
> If it was buffering (steered from within the binary), I don't understand why
> I see the output lines on the shell directly, but in the Perl program I
> don't.
Your binary may behave differently when printing to a terminal
and to a pipe. The output library (glibc?) may do line buffering
on a terminal shell and block buffering for pipes. In the later
case the parent will only get to see some output if the binary
has printed more than $buffersize bytes or run longer than the
maximum flush interval before it is interrupted.
-Chris
------------------------------
Date: 1 Jul 2005 12:44:40 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: weird behavior with open and pipe
Message-Id: <da3dro$7qe$1@mamenchi.zrz.TU-Berlin.DE>
Moritz Karbach <moritz.karbach@desy.de> wrote in comp.lang.perl.misc:
> Hi Anno,
>
> > Buffering. The output is still in a buffer when the program gets killed,
> > so the data is lost. At least, that's consistent with what you're
> > seeing.
>
> Well the thing is, whem I'm running the executable directly on the shell, it
> immediately prints out some lines, then starts "hard working" without any
> output.
>
> I'm killing it during the "hard working" phase (in fact the watchdog of my
> Command class kills the whole process group, so any of the subprocesses
> launched by my shell fake binary gets killed as well).
>
> If it was buffering (steered from within the binary), I don't understand why
> I see the output lines on the shell directly, but in the Perl program I
> don't.
You overall description certainly made it look like a buffering problem.
If you think it's something else, give us code to check.
Anno
------------------------------
Date: 01 Jul 2005 14:18:51 GMT
From: Villy Kruse <vek@station02.ohout.pharmapartners.nl>
Subject: Re: weird behavior with open and pipe
Message-Id: <slrndcak6b.4a5.vek@station02.ohout.pharmapartners.nl>
On 1 Jul 2005 12:44:40 GMT,
Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
> Moritz Karbach <moritz.karbach@desy.de> wrote in comp.lang.perl.misc:
>> Hi Anno,
>>
>> > Buffering. The output is still in a buffer when the program gets killed,
>> > so the data is lost. At least, that's consistent with what you're
>> > seeing.
>>
>> Well the thing is, whem I'm running the executable directly on the shell, it
>> immediately prints out some lines, then starts "hard working" without any
>> output.
>>
>> I'm killing it during the "hard working" phase (in fact the watchdog of my
>> Command class kills the whole process group, so any of the subprocesses
>> launched by my shell fake binary gets killed as well).
>>
>> If it was buffering (steered from within the binary), I don't understand why
>> I see the output lines on the shell directly, but in the Perl program I
>> don't.
>
> You overall description certainly made it look like a buffering problem.
> If you think it's something else, give us code to check.
>
The desribed behaviour is still consistent with normal buffering behaviour.
It is quite common that programs writing to stdout will keep the
data in the buffer until it is full, which is in some cases 4096 bytes.
When stdout is a terminal the buffer is sent to the terminal for every
newline. That is why "command | cat" and "command" behaves differently.
Villy
------------------------------
Date: 01 Jul 2005 14:18:53 GMT
From: Villy Kruse <vek@station02.ohout.pharmapartners.nl>
Subject: Re: weird behavior with open and pipe
Message-Id: <slrndcak1u.4a5.vek@station02.ohout.pharmapartners.nl>
On 1 Jul 2005 12:44:40 GMT,
Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
> Moritz Karbach <moritz.karbach@desy.de> wrote in comp.lang.perl.misc:
>> Hi Anno,
>>
>> > Buffering. The output is still in a buffer when the program gets killed,
>> > so the data is lost. At least, that's consistent with what you're
>> > seeing.
>>
>> Well the thing is, whem I'm running the executable directly on the shell, it
>> immediately prints out some lines, then starts "hard working" without any
>> output.
>>
>> I'm killing it during the "hard working" phase (in fact the watchdog of my
>> Command class kills the whole process group, so any of the subprocesses
>> launched by my shell fake binary gets killed as well).
>>
>> If it was buffering (steered from within the binary), I don't understand why
>> I see the output lines on the shell directly, but in the Perl program I
>> don't.
>
> You overall description certainly made it look like a buffering problem.
> If you think it's something else, give us code to check.
>
The desribed behaviour is still consistent with normal buffering behaviour.
It is quite common that programs writing to stdout will keep the
data in the buffer until it is full, which is in some cases 4096 bytes.
When stdout is a terminal the buffer is sent to the terminal for every
newline. That is why "command | cat" and "command" behaves differently.
Villy
------------------------------
Date: Fri, 01 Jul 2005 17:43:35 +0200
From: Moritz Karbach <moritz.karbach@desy.de>
Subject: Re: weird behavior with open and pipe
Message-Id: <da3ob7$iqsj$1@claire.desy.de>
Hi Christian (and the others),
> Your binary may behave differently when printing to a terminal
> and to a pipe.
ok, I didn't know that something like that is possible... So it is unlikely,
that I see anything from the command if it gets killed.
Or are there some standard methods to turn output buffering off? Some
environment variable, for instance? Maybe I can simulate a terminal within
the child before it exec's the command?
Thanks for your help,
- Moritz
------------------------------
Date: Fri, 01 Jul 2005 18:21:25 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: weird behavior with open and pipe
Message-Id: <da3u2l$ije$1@redhat2.bham.ac.uk>
Moritz Karbach wrote:
> Hi Christian (and the others),
>
>>Your binary may behave differently when printing to a terminal
>>and to a pipe.
>
> ok, I didn't know that something like that is possible... So it is unlikely,
> that I see anything from the command if it gets killed.
>
> Or are there some standard methods to turn output buffering off? Some
> environment variable, for instance?
Not that I know of.
> Maybe I can simulate a terminal within
> the child before it exec's the command?
I _Expect_ there's something on CPAN. :-)
------------------------------
Date: Fri, 01 Jul 2005 19:55:49 +0200
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: weird behavior with open and pipe
Message-Id: <42c58399$0$10817$9b4e6d93@newsread4.arcor-online.net>
Moritz Karbach schrieb:
> Hi Christian (and the others),
>
>>Your binary may behave differently when printing to a terminal
>>and to a pipe.
>
> ok, I didn't know that something like that is possible... So it is unlikely,
> that I see anything from the command if it gets killed.
>
> Or are there some standard methods to turn output buffering off? Some
> environment variable, for instance? Maybe I can simulate a terminal within
> the child before it exec's the command?
I'm not the big POSIX crack and there may be ways, but
no trivial one that I know of. Normally selecting stream
modes is all up to the program that owns the stream. Maybe
the author of the binary program has built in means to flush
the buffer (e.g. by sending it a SIGUSR1 or SIGUSR2, I believe
some GNU tools did just that).
-Chris
------------------------------
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 8219
***************************************
