[19932] in Perl-Users-Digest
Perl-Users Digest, Issue: 2127 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Nov 14 00:07:50 2001
Date: Tue, 13 Nov 2001 21:05:10 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <1005714309-v10-i2127@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Tue, 13 Nov 2001 Volume: 10 Number: 2127
Today's topics:
Re: -M $file on win32 (Joe Smith)
Re: Can you help optimize this?? <goldbb2@earthlink.net>
Re: detecting OLE failure in perl? <vfoitzik@gmx.net>
Re: ebcdic (was Re: Unencoding) <mgjv@tradingpost.com.au>
Re: ebcdic (was Re: Unencoding) <flavell@mail.cern.ch>
Re: ebcdic (was Re: Unencoding) <mgjv@tradingpost.com.au>
Re: ebcdic (was Re: Unencoding) <mgjv@tradingpost.com.au>
ebcdic, was Re: Unencoding <flavell@mail.cern.ch>
Re: ebcdic, was Re: Unencoding <mgjv@tradingpost.com.au>
Re: ebcdic, was Re: Unencoding <joe+usenet@sunstarsys.com>
Re: ebcdic, was Re: Unencoding <mgjv@tradingpost.com.au>
Re: ebcdic, was Re: Unencoding <uri@stemsystems.com>
Re: Everything but the if... <goldbb2@earthlink.net>
help? build problems (apparently malloc-related) <cak@putzl.com>
Re: help? build problems (apparently malloc-related) <cak@putzl.com>
Re: how do I use gzip <bart.lateur@skynet.be>
Re: Memory mgt and GC in perl 5.005_3 (Logan Shaw)
Re: module to help change login shell (no..chsh is not <none@nothere.please.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 14 Nov 2001 00:30:50 GMT
From: inwap@best.com (Joe Smith)
Subject: Re: -M $file on win32
Message-Id: <_WiI7.4075$Le.99725@sea-read.news.verio.net>
In article <5of2vtse49127t2iof9lf233uc6apkuu6p@4ax.com>,
Lars Oeschey <oeschey@media-saturn.com> wrote:
>On Tue, 13 Nov 2001 10:18:16 +0100, "Dr. Peter Dintelmann"
><Peter.Dintelmann@dresdner-bank.com> wrote:
>
>> Thus I suspect you wanted to type
>> if (-f "$localdir/$datei") { ... }
>> Is this of any help to you?
>> Peter
>
>hm, this really solved the problem of the multi-dot-files, I see them
>all now. But with the same construction, the -M doesn't work, I just
>get nothing back...
>this is the code:
>
>opendir (SAVE, "$localdir");
>while ($datei = readdir (SAVE)) {
> if (-f "$localdir/$datei") {
> $alter = -M "$localfile/$datei";
Change that to
$alter = -M "$localdir/$datei";
or
$alter = -M _;
In other words, do what the previous answer said to do. Look into how
a plain underscore is treated by -f and -M.
-Joe
P.S. Perl would have told you where the typo was if you had
put the line 'use warnings;' at the top of your program.
--
See http://www.inwap.com/ for PDP-10 and "ReBoot" pages.
------------------------------
Date: Tue, 13 Nov 2001 18:20:59 -0500
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Can you help optimize this??
Message-Id: <3BF1AADA.20E75AFB@earthlink.net>
Rob wrote:
>
> I realize that index is a horrible function for speed. Here is what
> my program looks like (more pseudo than code, FYI)
Very often, optomizing a program is a matter of picking the most
efficient data structure, not a matter of tweaking the algorithm.
Here's a slightly better data structure.
my %products = map {$_=>1} qw(PA PN PR PT);
my @customers = qw(A95412);
my %purchases = (A95412 => [qw(AB AC AF GR PR)]);
foreach my $customer (@customers)
{
foreach my $products (grep $products{$_}, @{$purchases{$customer}})
{
print "Customer $customer purchased product $product.\n";
}
}
Another possibility would be to make the values of %purchases be
hashrefs whose structure is similar to %products, and to make products
into an array. That is:
my @products = qw(PA PN PR PT)
my @customers = qw(A95412);
my %purchases = (A95412 => {map {$_=>1} qw(AB AC AF GR PR)});
foreach my $customer (@customers)
{
foreach my $products (grep $purchase{$customer}{$_}, @products)
{
print "Customer $customer purchased product $product.\n";
}
}
Which will be faster depends on a number of things.
--
Klein bottle for rent - inquire within.
------------------------------
Date: Wed, 14 Nov 2001 00:41:00 +0100
From: Victor Foitzik <vfoitzik@gmx.net>
Subject: Re: detecting OLE failure in perl?
Message-Id: <MPG.165bcdf3547587a2989684@news.cis.dfn.de>
alan_spamoff@deterministicnetworks.com wrote:
> I'm having trouble detecting OLE success/failure status, and any clues would
> be much appreciated. It's working in VB but I really don't want to go that
> way.
>
> working VB:
> database.Export "File", szDbPath, "adsfile.idt" : CheckError
>
> failing perl:
> $database->Export("File", $CurrentDirectory, "adsfile.idt") ||
> die "Export failed $!";
>
> -- the perl always takes the "die" path even when the export has succeeded
> (which I know because the exported file is correct)
[...]
exactly what does $database->Export return ? IMHO it is possible that
the Export method succeeds, but returns a false value. Try something
like:
use Data::Dumper;
# ... your code here
my $result = $database->Export("File", $CurrentDirectory, adsfile.idt");
print Dumper($result);
you can exactly see, what is being returned by Export and handle this
correctly.
HTH
Victor
------------------------------
Date: Tue, 13 Nov 2001 23:27:31 GMT
From: Martien Verbruggen <mgjv@tradingpost.com.au>
Subject: Re: ebcdic (was Re: Unencoding)
Message-Id: <slrn9v3b3s.6ia.mgjv@verbruggen.comdyn.com.au>
On Tue, 13 Nov 2001 22:32:36 GMT,
Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "MV" == Martien Verbruggen <mgjv@tradingpost.com.au> writes:
>
> MV> To come back to the topic: Is there anyone with an EBCDIC machine
> MV> reading this that could test that code either to confirm my suspicion
> MV> that it won't work, or to prove perl more portanle than that (doubt
> MV> it). If it doesn't work, I might try to work up a patch for Lincoln
> MV> Stein, since he uses this stuff in CGI.pm as well.
>
> i changed the subject to reflect the topic.
>
> there are definitely ebcdic boxes running web servers out there but i
> bet they have to do all their http/url work in ascii as that is what
> url's and http headers are defined to have. also on all of those boxes
I know of a few EBCDIC machines (on AS/400) instances doing Web
serving work, but of none that use Perl for it.
> (i think you mentioned the actual subsystems) they have ascii systems
> you can run. IIRC a recent big ibm 390 ran something like 17,000 linux
> sessions. :) so anyone running web stuff on an ebcdic box would know
> what to do or run it under an ascii subsystem. also i believe that 5.6
> is totally flummoxed under ebcdic. so how perl itself handles an ascii
> url under ebcdic may be a moot point.
I didn't know they'd broken Perl on EBCDIC.
> then again, i could be totally wrong. my ebcdic days (thankfully) ended
> decades ago.
I've never had to use Perl on one, but C suffers from the same sort of
problems.
For people still reading, and maybe wondering what the heck
this is about:
The numeric value and ordering of the characters in the base character
set is different on ASCII and EBCDIC. The URL encoding (and other
related encodings) are based on ASCII character values, while the pack
'C' construction uses (AFAIK) the system's underlying idea of what a
character's value should be. As long as they match closely enough, the
presented code will work, otherwise they won't.
Martien
--
|
Martien Verbruggen | Begin at the beginning and go on till
Trading Post Australia Pty Ltd | you come to the end; then stop.
|
------------------------------
Date: Wed, 14 Nov 2001 01:00:34 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: ebcdic (was Re: Unencoding)
Message-Id: <Pine.LNX.4.30.0111140051200.28574-100000@lxplus013.cern.ch>
On Nov 13, Martien Verbruggen inscribed on the eternal scroll:
> character's value should be. As long as they match closely enough, the
> presented code will work, otherwise they won't.
I think you'll find there's a perfectly good answer in CGI.pm (what a
surprise!). See the Util.pm module, functions escape, unescape
At appropriate moments he translates between EBCDIC and ASCII.
(I'm looking at version 2.78 while typing this).
The problem is maybe not the one you anticipated(?) The character
classes and conversion to hex work just great, but the notation %xx in
the URL-encoded strings must represent the ASCII value of the
character, even on an EBCDIC platform!
Sorry, I was "thinking on my feet" there...
all the best
------------------------------
Date: Wed, 14 Nov 2001 02:32:57 GMT
From: Martien Verbruggen <mgjv@tradingpost.com.au>
Subject: Re: ebcdic (was Re: Unencoding)
Message-Id: <slrn9v3lvi.6ia.mgjv@verbruggen.comdyn.com.au>
On Wed, 14 Nov 2001 01:00:34 +0100,
Alan J. Flavell <flavell@mail.cern.ch> wrote:
> On Nov 13, Martien Verbruggen inscribed on the eternal scroll:
>
>> character's value should be. As long as they match closely enough, the
>> presented code will work, otherwise they won't.
>
> I think you'll find there's a perfectly good answer in CGI.pm (what a
> surprise!). See the Util.pm module, functions escape, unescape
I only browsed through CGI.pm itself, and find a few occurences of
mappings as the one under discussion:
in sub url
$url =~ s/([^a-zA-Z0-9_.%;&?\/\\:+=~-])/uc sprintf("%%%02x",ord($1))/eg;
in sub new:
(my $safename = $name) =~ s/([':%])/ sprintf '%%%02X', ord $1 /eg;
On second thought, these should work correctly, since ord() is
documented to return the ASCII value.
Indeed, in CGI::Utils the issue seems to be addressed by specifically
dealing with EBCDIC machines.
Looks like LDS has dealt with this issue already :) Good to know.
Another reason to prefer CGI.pm over any handrolled method.
> The problem is maybe not the one you anticipated(?) The character
The problem is at least not that CGI.pm uses the construct.
> classes and conversion to hex work just great, but the notation %xx in
> the URL-encoded strings must represent the ASCII value of the
> character, even on an EBCDIC platform!
My first reaction was more to the pack "C", which carries no
(documented) guarantee of ASCII semantics. Maybe pack "U" would be
more reliable.
I was hoping not to have to read the sources, but it looks like I
might have to :)
Martien
--
|
Martien Verbruggen | Think of the average person. Half of
Trading Post Australia Pty Ltd | the people out there are dumber.
|
------------------------------
Date: Wed, 14 Nov 2001 02:46:13 GMT
From: Martien Verbruggen <mgjv@tradingpost.com.au>
Subject: Re: ebcdic (was Re: Unencoding)
Message-Id: <slrn9v3moe.6ia.mgjv@verbruggen.comdyn.com.au>
On Wed, 14 Nov 2001 02:32:57 GMT,
Martien Verbruggen <mgjv@tradingpost.com.au> wrote:
>
> On second thought, these should work correctly, since ord() is
> documented to return the ASCII value.
On third thought, and reading of perlebcdic again:
IDENTIFYING CHARACTER CODE SETS
To determine the character set you are running under from
perl one could use the return value of ord() or chr() to
test one or more character values. For example:
$is_ascii = "A" eq chr(65);
$is_ebcdic = "A" eq chr(193);
Looks like the ord() entry in perlfunc is broken, or perlebcdic is
broken.
perlebcdic also explicitly states that pack "C" will differ depending
on the character set, as well as ord(), chr(), *printf "%c". The
commonly given advice to print "\012\015" to get a guaranteed CRLF
combo is also not portable to some EBCDIC encodings.
I guess this answers my question... Assuming of course that the
perlebcdic documentation is up to date :)
Martien
--
|
Martien Verbruggen | I took an IQ test and the results
Trading Post Australia Pty Ltd | were negative.
|
------------------------------
Date: Wed, 14 Nov 2001 00:25:26 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: ebcdic, was Re: Unencoding
Message-Id: <Pine.LNX.4.30.0111132335360.28574-100000@lxplus013.cern.ch>
On Nov 13, Martien Verbruggen inscribed on the eternal scroll:
> To come back to the topic: Is there anyone with an EBCDIC machine
> reading this that could test that code either to confirm my suspicion
> that it won't work,
(I'm afraid I haven't, but as a former EBCDIC user I'm nevertheless
interested...)
I think the key issue that you're asking about (correct me if I'm
mistaken, as there's been - no fault of yours - too much flamethrowing
since anything worthwhile happened) is this: whether character classes
like [a-fA-F0-9] will work correctly to identify hex digits on an
EBCDIC-based machine?
My hypothesis is "yes".
The release notes (I found this thanks to Google) for 5.005.03 say:
EBCDIC: Character class ranges ([a-z]) now work in non-ASCII
platforms.
I feel confident that "work" means what you and any other reasonable
person would expect it to mean.
Google also found a version of the 'perlre' documentation at
ActiveState which says explicitly:
The following all specify the same class of three characters: [-az],
[az-], and [a\-z]. All are different from [a-z], which
specifies a class containing twenty-six
characters, even on EBCDIC based coded character sets.
Note that perldoc perlebcdic says:
The .. range operator treats certain character ranges with care on EBCDIC
machines. For example the following array will have twenty six elements on
either an EBCDIC machine or an ASCII machine:
@alphabet = ('A'..'Z'); # $#alphabet == 25
, showing that this kind of issue has been given due consideration.
These are POSIX semantics, aren't they?
I've seen it stated elsewhere however that EBCDIC is completely broken
in 5.6.0.
Hope this helps a bit.
To Uri: it's surely evident from the CGI.pm code that Lincoln is
making provision for an EBCDIC-based CGI API, so I've always assumed
there must be one or more in existence - he'd hardly go to that effort
if it wasn't needed! Recall that the CGI specification is about the
programming interface between the CGI process and the HTTPD web
server: it can and does follow different rules than the external HTTP
protocol between the server and its client, which indeed would need to
use an ASCII-based protocol, no argument there.
------------------------------
Date: Wed, 14 Nov 2001 02:23:37 GMT
From: Martien Verbruggen <mgjv@tradingpost.com.au>
Subject: Re: ebcdic, was Re: Unencoding
Message-Id: <slrn9v3le2.6ia.mgjv@verbruggen.comdyn.com.au>
On Wed, 14 Nov 2001 00:25:26 +0100,
Alan J. Flavell <flavell@mail.cern.ch> wrote:
> On Nov 13, Martien Verbruggen inscribed on the eternal scroll:
>
>> To come back to the topic: Is there anyone with an EBCDIC machine
>> reading this that could test that code either to confirm my suspicion
>> that it won't work,
>
> (I'm afraid I haven't, but as a former EBCDIC user I'm nevertheless
> interested...)
>
> I think the key issue that you're asking about (correct me if I'm
> mistaken, as there's been - no fault of yours - too much flamethrowing
> since anything worthwhile happened) is this: whether character classes
> like [a-fA-F0-9] will work correctly to identify hex digits on an
> EBCDIC-based machine?
>
> My hypothesis is "yes".
I think character classes will work, because there's some special
treatment for these thigns (I also think magic increment and the ..
operator do special things for this). However, the pack interface, and
probably sprintf as well, are more likely to use a low level binding
to the underlying C library, which would result in numeric values of
characters being translated according to the current character set.
It's only this particular situation that I was concerned about.
IIRC the special case of character classes came up not that long ago
on clp.misc.
> The release notes (I found this thanks to Google) for 5.005.03 say:
>
> EBCDIC: Character class ranges ([a-z]) now work in non-ASCII
> platforms.
:)
> Note that perldoc perlebcdic says:
>
> The .. range operator treats certain character ranges with care on EBCDIC
> machines. For example the following array will have twenty six elements on
> either an EBCDIC machine or an ASCII machine:
I should have rad your complete post before answering the first
paragraph :)
Martien
--
|
Martien Verbruggen |
Trading Post Australia Pty Ltd | What's another word for Thesaurus?
|
------------------------------
Date: 13 Nov 2001 20:08:06 -0500
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: ebcdic, was Re: Unencoding
Message-Id: <m3snbi2m89.fsf@mumonkan.sunstarsys.com>
"Alan J. Flavell" <flavell@mail.cern.ch> writes:
> On Nov 13, Martien Verbruggen inscribed on the eternal scroll:
>
> > To come back to the topic: Is there anyone with an EBCDIC machine
> > reading this that could test that code either to confirm my suspicion
> > that it won't work,
>
> (I'm afraid I haven't, but as a former EBCDIC user I'm nevertheless
> interested...)
>
> I think the key issue that you're asking about (correct me if I'm
> mistaken, as there's been - no fault of yours - too much flamethrowing
> since anything worthwhile happened) is this: whether character classes
> like [a-fA-F0-9] will work correctly to identify hex digits on an
> EBCDIC-based machine?
>
> My hypothesis is "yes".
[Disclaimer- I've never used an EBCDIC machine; comments below are
based on reading the relevant documentation and source code]
I'd guess you are right, but OTOH something like "%2b" (ASCII)
won't directly match %[a-fA-F0-9]{2} on EBCDIC; I think the the
ASCII codeset for the original www-urlencoded string would first
need to be converted to EBCDIC. Once that's done, then I suspect
the substitution will work as expected.
I'm pretty sure the CGI 1.1 spec requires the server to perform the
necessary character-set translations: apache's mod_cgi does this
automatically. I suspect it does so on the entire input/output
streams (and not just the headers, although there seems to be
some confusion about this in the source's comments), so binary
data might need additional conversion. I'd be quite pleasantly
surprised to learn that mod_perl did it also, but I rather doubt it;
there's no mention of EBCDIC in the mod_perl-1.26 package.
--
Joe Schaefer "Peace cannot be kept by force. It can only be achieved by
understanding."
--Albert Einstein
------------------------------
Date: Wed, 14 Nov 2001 03:36:19 GMT
From: Martien Verbruggen <mgjv@tradingpost.com.au>
Subject: Re: ebcdic, was Re: Unencoding
Message-Id: <slrn9v3pmc.6ia.mgjv@verbruggen.comdyn.com.au>
On 13 Nov 2001 20:08:06 -0500,
Joe Schaefer <joe+usenet@sunstarsys.com> wrote:
> "Alan J. Flavell" <flavell@mail.cern.ch> writes:
>
>> On Nov 13, Martien Verbruggen inscribed on the eternal scroll:
>>
>> > To come back to the topic: Is there anyone with an EBCDIC machine
>> > reading this that could test that code either to confirm my suspicion
>> > that it won't work,
>>
>> (I'm afraid I haven't, but as a former EBCDIC user I'm nevertheless
>> interested...)
>>
>> I think the key issue that you're asking about (correct me if I'm
>> mistaken, as there's been - no fault of yours - too much flamethrowing
>> since anything worthwhile happened) is this: whether character classes
>> like [a-fA-F0-9] will work correctly to identify hex digits on an
>> EBCDIC-based machine?
>>
>> My hypothesis is "yes".
>
> [Disclaimer- I've never used an EBCDIC machine; comments below are
> based on reading the relevant documentation and source code]
>
> I'd guess you are right, but OTOH something like "%2b" (ASCII)
I suppose you meant "%02x" ?
> won't directly match %[a-fA-F0-9]{2} on EBCDIC; I think the the
> ASCII codeset for the original www-urlencoded string would first
> need to be converted to EBCDIC. Once that's done, then I suspect
> the substitution will work as expected.
I'm not too afraid about the matching part [1], because I think that
that should be covered by Perl's internals (assuming that what you're
matching against is in the current character encoding). The code
fragment was:
$code =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
It's more the substitution bit that worries me a bit, and a thorough
reading of perlebcdic seems to support that the pack there is not at
all portable. A URL is encoded according to ASCII or Unicode values,
so that %30 translates to the character 0, and %5A to the character Z.
On ASCII systems, pack "C", hex("5A") will give you the character Z,
but on EBCDIC systems, it won't.
> I'm pretty sure the CGI 1.1 spec requires the server to perform the
> necessary character-set translations: apache's mod_cgi does this
> automatically. I suspect it does so on the entire input/output
> streams (and not just the headers, although there seems to be
> some confusion about this in the source's comments), so binary
> data might need additional conversion. I'd be quite pleasantly
> surprised to learn that mod_perl did it also, but I rather doubt it;
> there's no mention of EBCDIC in the mod_perl-1.26 package.
I _think_ we're talking about a different stage in the process. The
translation from the bytes what went over the network into a
representation for local character encoding should be handled by the
server, I believe. But you'd still end up with a URL-encoded string
(albeit in the local character set) which you have to decode. This
decoding process will, irrespective of platform, need to use the ASCII
table. pack "C" won't do that. pack "U" might (not sure about that
one , the perl source translates it into a UTF-8 encoded character.
Not sure how that would come out). Even chr won't work here, since
that has the same problems as pack "C".
Martien
[1] I'm sorry if I wasn't clear enough about which part exactly I was
worried about. I seem to have caused some confusion about this.
--
|
Martien Verbruggen | In the fight between you and the
Trading Post Australia Pty Ltd | world, back the world - Franz Kafka
|
------------------------------
Date: Wed, 14 Nov 2001 04:44:04 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: ebcdic, was Re: Unencoding
Message-Id: <x7adxqhseu.fsf@home.sysarch.com>
>>>>> "AJF" == Alan J Flavell <flavell@mail.cern.ch> writes:
AJF> To Uri: it's surely evident from the CGI.pm code that Lincoln is
AJF> making provision for an EBCDIC-based CGI API, so I've always
AJF> assumed there must be one or more in existence - he'd hardly go
AJF> to that effort if it wasn't needed! Recall that the CGI
AJF> specification is about the programming interface between the CGI
AJF> process and the HTTPD web server: it can and does follow
AJF> different rules than the external HTTP protocol between the
AJF> server and its client, which indeed would need to use an
AJF> ASCII-based protocol, no argument there.
cgi ebcdic support is news to me. :)
i understand your delineation between http and cgi and i know it
well. it would be up to the server to do the conversions but would it
translate (from ascii to ebcdic) the URL encoded args or post data for
the cgi? or is that up to the cgi? and what about the headers generated
by the cgi? just a whole mess of worms there and what about even trying
to write portable perl cgi across the ebcdic/ascii range?
yoiks! (let moronzilla answer, she is back :( and knows all about this)
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
-- Stem is an Open Source Network Development Toolkit and Application Suite -
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Tue, 13 Nov 2001 21:25:51 -0500
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Everything but the if...
Message-Id: <3BF1D62F.9A2FBD74@earthlink.net>
martinblack wrote:
>
> Hi folks, another week, another mystery. Below is a snippet of code
> that worked fine until I added the: if ($query eq 'set'){ do...} else
> { blah... }. The println works fine in either case, printing the SQL
> commands, but if $query eq 'set' all I get is the one print line
> stating the SQL command. Why won't the if statement work? Any help
> would be greatly appreciated. Below is the snippet.
It would help a bit if you would state a bit more clearly what you want
your code to do. It's not exactly clear.
> Ps. I've tried wrapping the prepare and executes in eval, but $@ is
> always empty.
That won't make a difference unless RaiseError is set. And if
RaiseError was set, then you would detect the error anyway without the
eval... [somehow or other, such as a 5xx error if this is a cgi].
Also, you code isn't exactly easy to read. I would suggest running the
perltidy program on it before posting it to usenet. It would help us
quite a bit in reading and understanding it.
Your code, minus error checking, and factoring out common parts, looks
something like this:
$sth=$dbh->prepare(q[SELECT * FROM product WHERE title LIKE ?]);
if( $query eq 'set' ) {
$sth->execute( $query );
} else {
$sth->execute("%" . $query . "%");
}
print "This is the sql: $sth->{Statement} \n";
while( my $x = $sth->fetchrow_hashref("NAME_lc") ) {
my $io = join("|", @$x{qw(company_id product_id
title description spex price)}) . "\n\n";
print "<p>We have $io<br>";
}
print "There were ", $sth->rows, " rows fetched\n";
Now, your problem was, "if $query eq 'set' all I get is the one print
line stating the SQL command," essentially saying that if you leave off
the % before and after the query, you end up with zero rows fetched.
Without knowing what your data is, I would have to guess that your
program is running exactly correctly -- it is only fetching those rows
whose title field is "set", exactly. If you want it to fetch those rows
whose title field *contains* the substring "set", then add back in the %
thingies. This is an SQL problem, not a perl problem.
--
Klein bottle for rent - inquire within.
------------------------------
Date: Tue, 13 Nov 2001 16:45:02 -0800
From: Chris Kantarjiev <cak@putzl.com>
Subject: help? build problems (apparently malloc-related)
Message-Id: <3BF1BE8E.36DD87A9@putzl.com>
I'm trying to rebuild 5.6.1 on solaris (with gcc) to get GDBM support (I
didn't have it installed on the system before). I used to be able to
build perl cleanly, but I've broken something, seemingly around which
malloc to use and what .h files to include.
I now get a lot of errors like
ODBM_File.xs: In function `XS_ODBM_File_DESTROY':
ODBM_File.xs:121: warning: passing arg 1 of `Perl_safefree' from
incompatible pointer type
which I don't recall seeing before. Ultimately, the build breaks here:
cd sdbm && make all
gcc -c -I../../.. -fno-strict-aliasing -I/usr/local/include
-D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -O -DVERSION=\"0.10\" -DXS_VERSION=\"0.10\"
-fPIC -I.
./../.. -DSDBM -DDUFF sdbm.c
sdbm.c:40: conflicting types for `malloc'
/usr/include/iso/stdlib_iso.h:100: previous declaration of `malloc'
sdbm.c:41: conflicting types for `free'
/usr/include/iso/stdlib_iso.h:96: previous declaration of `free'
*** Error code 1
make: Fatal error: Command failed for target `sdbm.o'
Current working directory /opt/source/perl-5.6.1/ext/SDBM_File/sdbm
*** Error code 1
make: Fatal error: Command failed for target `sdbm/libsdbm.a'
Current working directory /opt/source/perl-5.6.1/ext/SDBM_File
*** Error code 1
make: Fatal error: Command failed for target
`lib/auto/SDBM_File/SDBM_File.so'
I'm stumped. I've redone the Configure step a couple of times with and
without using the Perl malloc - neither one gets me a clean build...
Thanks,
chris
------------------------------
Date: Tue, 13 Nov 2001 16:59:01 -0800
From: Chris Kantarjiev <cak@putzl.com>
Subject: Re: help? build problems (apparently malloc-related)
Message-Id: <3BF1C1D5.48B66673@putzl.com>
Oh. I didn't dig deeply enough; it appears that I ended up with Malloc_t
set to char * instead of void * somehow... fixing that seems to have
solved all my problems.
Sorry for the interruption.
------------------------------
Date: Wed, 14 Nov 2001 01:48:44 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: how do I use gzip
Message-Id: <d4j3vt8es27gq0bs1vaf5r2neoimf0ji8a@4ax.com>
Martien Verbruggen wrote:
>I tend to use Compress::Zlib for gzipped files, sometimes together
>with Archive::Tar if I need to pack up multiple files.
You can rely on Archive::Tar to use Compress::Zlib for you if you need
it, just like you can rely on tar to call for gzip if you tell it to
with the -z command line switch. Or, in short: Archive::Tar can read and
write .tar.gz files. For the API, it's just a matter of adding a second,
true, parameter to the read() and write() method calls.
I'm not really sure how recent versions of Archive::Tar (mine's quite
old) deal with archives that are too large to hold in memory.
--
Bart.
------------------------------
Date: 13 Nov 2001 20:37:30 -0600
From: logan@cs.utexas.edu (Logan Shaw)
Subject: Re: Memory mgt and GC in perl 5.005_3
Message-Id: <9sslda$8qo$1@charity.cs.utexas.edu>
In article <9sru20$1af3$1@agate.berkeley.edu>,
Arvin Portlock <temp133@hotmail.com> wrote:
>My question is how do I clean up the previous tree? I would simply undef
>the root node but each node has a reference to its parent as well as
>references to its siblings and its children. I assume perl's GC relies on
>reference counting and since each node may have two references pointing
>to it, nothing will get cleaned up.
Almost. It's not because the nodes have two references[1]. It's
because there is a cycle. (Your "tree" is not technically a tree.
It's a directed graph with cycles.)
The minimum you have to do to get Perl's garbage collector to clean up
any data structure is to remove external references to it (through
other data structures and through variable names bound to something in
it) and break all cycles within it. In your case, the easiest way to
do this is to break the link from each child to its parent. Then
you'll have a true tree, and when you break the link to the root, the
rest of it will fall like dominoes.
There's some documentation on garbage collection in Perl available via
"perldoc perlobj" if you want it. It's under a heading called
"Two-Phased Garbage Collection".
- Logan
[1] Here's an example of a data structure that will be fully
garbage collected even though $x's value has more than one
reference to it:
my $root;
{
my $x = 42;
$root = [ [ \$x ], [ \$x ] ];
# now three references to $x exist, one through its
# name and the other two through this data structure.
}
# now two references to $x exist.
$root = undef;
# $x has been reclaimed here
--
"In order to be prepared to hope in what does not deceive,
we must first lose hope in everything that deceives."
Georges Bernanos
------------------------------
Date: Wed, 14 Nov 2001 04:23:36 GMT
From: jeff <none@nothere.please.net>
Subject: Re: module to help change login shell (no..chsh is not available on solaris...)
Message-Id: <o9r3vtgt78opt3p118sv33nhrf9o20eav0@4ax.com>
On the glorious day of Sun, 11 Nov 2001 23:13:19 +0200, "Stuart Gall"
<stuart@otenet.gr> felt the need to utter
>"jeff" <none@nothere.please.net> wrote in message
>news:ojotut08hh4rm9cqo8304ud56a3d7aubfc@4ax.com...
>> On the glorious day of 10 Nov 2001 17:19:37 -0600, logan@cs.utexas.edu
>> (Logan Shaw) felt the need to utter
>>
>> >In article <kdarutggbmbko8btss4ajugeqbh25jotij@4ax.com>, jeff <hk63a>
>wrote:
>> >>Solaris does not have chsh functionality any longer (bastards..)
>> >>so, i am trying to write a setuid (*GASP*) script to enable users to
>> >>change their passwords and gecos info without bothering me anymore!!
>> > :
>> > :
>> >>I'd rather not rewrite the whole /etc/passwd file each time manually
>> >>using "open" and such..thats just waiting to crash the system.
>> >
>> >So call /usr/bin/passwd and have it make the changes to /etc/passwd.
>> >
>>
>> Ive been trying to do this, granted Im only a novice perl programmer,
>> so Im sure im missing something important...notably, I seem to
>> remember somethng about perl not just letting perl script be setuid,
>Dont see why perl would care or even know. Most kernels wont let you setuid
>on any script by default.
>
>> in that it will still not just let anyone do anything.
>> I just would always get "Permission denied" even when I called
>> "/usr/bin/passwd -e <username>" with a suid script...did it with c,
>> but..that was last night when i got fed up with perl :-(
>You do not need to be setuid to call passwd. Just call it from the sctipt.
true, but you it has to be if I am trying to do "passwd -e" .. only
superuser can change the login shell..so, about every semesterr, for
two weeks, im changing everyones login shell from this, to that, and
back again many....many times..and in no particular order nor all at
one time
>
>You are not trying to do this from a cgi are you ?
noooooooo....
just started with trying to use suid root perl script as it's
inherently more secure than a c program (or so I've heard....?)
------------------------------
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 2127
***************************************
