[28915] in Perl-Users-Digest
Perl-Users Digest, Issue: 159 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 21 16:09:40 2007
Date: Wed, 21 Feb 2007 13:09:08 -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 Wed, 21 Feb 2007 Volume: 11 Number: 159
Today's topics:
Re: behavior of my print function call <someone@example.com>
fork()-ing questions <dale.schmitz@offutt.af.mil>
Re: fork()-ing questions <ddunham@redwood.taos.com>
Re: fork()-ing questions <dale.schmitz@offutt.af.mil>
Re: fork()-ing questions anno4000@radom.zrz.tu-berlin.de
Re: fork()-ing questions <jgibson@mail.arc.nasa.gov>
Re: Mystry CGI Perl from new Redhat server <raymond.chui@nospam.noaa.gov>
Re: Passing an array of arrays to an external function joakim.grahl@gmail.com
perl CPU utilization and socket I/O skyn3t@gmail.com
Running Java file and capturing output <mariecuddy@gmail.com>
Re: Running Java file and capturing output <jgibson@mail.arc.nasa.gov>
Re: Subclassing CGI::Pretty dies instantly in ->new , b <jeremy@chaos.org.uk>
Re: Subclassing CGI::Pretty dies instantly in ->new , b <jeremy@chaos.org.uk>
Re: Subclassing CGI::Pretty dies instantly in ->new , b <uri@stemsystems.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 21 Feb 2007 19:30:48 GMT
From: "John W. Krahn" <someone@example.com>
Subject: Re: behavior of my print function call
Message-Id: <I51Dh.123344$Oa.32730@edtnps82>
Joe Smith wrote:
> John W. Krahn wrote:
>> Joe Smith wrote:
>
>>> print $fh ($a+$b)/$c; <==> (print $fh ($a+$b)) / $c;
>>
>> Incorrect:
>>
>> $ perl -MO=Deparse,-p -e'print $fh ($a+$b)/$c;'
>> print($fh (($a + $b) / $c));
>
> That wasn't what I expected, but you're right.
The rule "It looks like a function, therefore it is a function" only works if
the parenthesis directly follows the function name. In your example there was
a filehandle between the function name and the parenthesis so it looks like an
operator instead of a function.
John
--
Perl isn't a toolbox, but a small machine shop where you can special-order
certain sorts of tools at low cost and in short order. -- Larry Wall
------------------------------
Date: 21 Feb 2007 11:47:03 -0800
From: "Monty" <dale.schmitz@offutt.af.mil>
Subject: fork()-ing questions
Message-Id: <1172087223.312361.27090@s48g2000cws.googlegroups.com>
In researching the Perl fork() command, I've come across many examples
of code and have been able to ascertain that when fork() is called,
the parent process retains it's own PID wil the child process takes a
PID of 0, at least in relation to the parent process.
This is pretty simple to see and understand, except for the
understanding that the process invoking fork() creates a clone of
itself, in which case the code examples I see leave one thing
unexplained. Take for instance the basic fork() routine similar to
what I've found on the web:
$pid = fork();
if ($pid == 0) {
# Then I'm the child process
} else {
# I'm the parent process
}
Programmatically correct considerations aside (I know I should include
an exit for the child process), I'm wondering--if the child process is
a clone of the parent--why the child process doesn't execute the "$pid
= fork()" statement. Is there some limitation to the amount of code
that gets "cloned"?
Secondly, I see a code snippet out there that confuses me and I'd just
like clarification of what it's saying. The following line:
unless ($pid = fork()) {
# Do something as the child process
}
'unless' is, as I understand it, used to loop when a condition is
false. False, in Perl, is the value 0 (along with undef and the empty
string). What is this the result of this fork() and it's effect on
the 'unless' statement? If the fork() produces a child process, then
doesn't the result of the entire '$pid = fork()' statement produce a
true value, as in the call to fork() executed correctly? If it did,
then doesn't the 'unless' statement test as true, meaning the loop
code gets bypassed?
It's all very confusing. Any clarification on this would be
appreciated.
------------------------------
Date: Wed, 21 Feb 2007 20:05:13 GMT
From: Darren Dunham <ddunham@redwood.taos.com>
Subject: Re: fork()-ing questions
Message-Id: <ZB1Dh.55$8x.27@newssvr14.news.prodigy.net>
Monty <dale.schmitz@offutt.af.mil> wrote:
> In researching the Perl fork() command, I've come across many examples
> of code and have been able to ascertain that when fork() is called,
> the parent process retains it's own PID wil the child process takes a
> PID of 0, at least in relation to the parent process.
Huh? No.
fork() is called once, but returns twice (in two separate processes).
The parent process has the same PID as the calling process. In that
process, the return code of fork() is the PID of the other process (the
child).
In the child process, a new PID is created and the return code of the
fork call is 0.
#!/usr/bin/perl
use warnings;
use strict;
print "Before fork, PID = $$\n";
my $code = fork;
print "After fork, PID = $$, fork returned $code.\n";
$ perl /tmp/fork.pl
Before fork, PID = 26341
After fork, PID = 26341, fork returned 26342.
After fork, PID = 26342, fork returned 0.
> This is pretty simple to see and understand, except for the
> understanding that the process invoking fork() creates a clone of
> itself, in which case the code examples I see leave one thing
> unexplained. Take for instance the basic fork() routine similar to
> what I've found on the web:
> $pid = fork();
> if ($pid == 0) {
> # Then I'm the child process
> } else {
> # I'm the parent process
> }
> Programmatically correct considerations aside (I know I should include
> an exit for the child process), I'm wondering--if the child process is
> a clone of the parent--why the child process doesn't execute the "$pid
> = fork()" statement. Is there some limitation to the amount of code
> that gets "cloned"?
No. The return of fork() is different in the two processes. $pid is
not the PID of the process, it's the result of the fork() call.
> Secondly, I see a code snippet out there that confuses me and I'd just
> like clarification of what it's saying. The following line:
> unless ($pid = fork()) {
> # Do something as the child process
> }
> 'unless' is, as I understand it, used to loop when a condition is
> false. False, in Perl, is the value 0 (along with undef and the empty
> string). What is this the result of this fork() and it's effect on
> the 'unless' statement? If the fork() produces a child process, then
> doesn't the result of the entire '$pid = fork()' statement produce a
> true value, as in the call to fork() executed correctly? If it did,
> then doesn't the 'unless' statement test as true, meaning the loop
> code gets bypassed?
No. This is all in the first sentence of fork.
$ perldoc -f fork
fork Does a fork(2) system call to create a new process running the
same program at the same point. It returns the child pid to
the parent process, 0 to the child process, or "undef" if the
fork is unsuccessful.
> It's all very confusing. Any clarification on this would be
> appreciated.
Reread the fork documentation in perldoc and understand the difference
between the return value of a function and the PID of a process ($$).
--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
------------------------------
Date: 21 Feb 2007 12:33:45 -0800
From: "Monty" <dale.schmitz@offutt.af.mil>
Subject: Re: fork()-ing questions
Message-Id: <1172090025.578027.306150@j27g2000cwj.googlegroups.com>
On Feb 21, 2:05 pm, Darren Dunham <ddun...@redwood.taos.com> wrote:
> Monty <dale.schm...@offutt.af.mil> wrote:
> > In researching the Perl fork() command, I've come across many examples
> > of code and have been able to ascertain that when fork() is called,
> > the parent process retains it's own PID wil the child process takes a
> > PID of 0, at least in relation to the parent process.
>
> Huh? No.
>
> fork() is called once, but returns twice (in two separate processes).
>
> The parent process has the same PID as the calling process. In that
> process, the return code of fork() is the PID of the other process (the
> child).
>
> In the child process, a new PID is created and the return code of the
> fork call is 0.
>
> #!/usr/bin/perl
> use warnings;
> use strict;
> print "Before fork, PID = $$\n";
> my $code = fork;
> print "After fork, PID = $$, fork returned $code.\n";
>
> $ perl /tmp/fork.pl
> Before fork, PID = 26341
> After fork, PID = 26341, fork returned 26342.
> After fork, PID = 26342, fork returned 0.
>
>
>
>
>
> > This is pretty simple to see and understand, except for the
> > understanding that the process invoking fork() creates a clone of
> > itself, in which case the code examples I see leave one thing
> > unexplained. Take for instance the basic fork() routine similar to
> > what I've found on the web:
> > $pid = fork();
> > if ($pid == 0) {
> > # Then I'm the child process
> > } else {
> > # I'm the parent process
> > }
> > Programmatically correct considerations aside (I know I should include
> > an exit for the child process), I'm wondering--if the child process is
> > a clone of the parent--why the child process doesn't execute the "$pid
> > = fork()" statement. Is there some limitation to the amount of code
> > that gets "cloned"?
>
> No. The return of fork() is different in the two processes. $pid is
> not the PID of the process, it's the result of the fork() call.
>
> > Secondly, I see a code snippet out there that confuses me and I'd just
> > like clarification of what it's saying. The following line:
> > unless ($pid = fork()) {
> > # Do something as the child process
> > }
> > 'unless' is, as I understand it, used to loop when a condition is
> > false. False, in Perl, is the value 0 (along with undef and the empty
> > string). What is this the result of this fork() and it's effect on
> > the 'unless' statement? If the fork() produces a child process, then
> > doesn't the result of the entire '$pid = fork()' statement produce a
> > true value, as in the call to fork() executed correctly? If it did,
> > then doesn't the 'unless' statement test as true, meaning the loop
> > code gets bypassed?
>
> No. This is all in the first sentence of fork.
>
> $ perldoc -f fork
> fork Does a fork(2) system call to create a new process running the
> same program at the same point. It returns the child pid to
> the parent process, 0 to the child process, or "undef" if the
> fork is unsuccessful.
>
> > It's all very confusing. Any clarification on this would be
> > appreciated.
>
> Reread the fork documentation in perldoc and understand the difference
> between the return value of a function and the PID of a process ($$).
>
> --
> Darren Dunham ddun...@taos.com
> Senior Technical Consultant TAOS http://www.taos.com/
> Got some Dr Pepper? San Francisco, CA bay area
> < This line left intentionally blank to confuse you. >- Hide quoted text -
>
> - Show quoted text -
Ok, thanks. This is getting somewhat clearer. I wasn't aware of the
perldoc command and have been using the web to answer questions. That
first statement in the fork() docs helps.
My second question is still foggy, and I may not have asked it
correctly. Considering the statment 'unless ($pid = fork())', if the
fork is successful, then the entire '$pid = fork()' statement is
evaluated as true and the loop code gets skipped--which is ok in the
parent process. Then, if the perldoc is to be taken at its word, the
child process that gets forked only consists of the code following the
fork() statement, which in this case is the loop code. I see the
benefit of coding exits in child process code.
How am I doing so far?
------------------------------
Date: 21 Feb 2007 20:55:46 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: fork()-ing questions
Message-Id: <543puiF1utgghU1@mid.dfncis.de>
Monty <dale.schmitz@offutt.af.mil> wrote in comp.lang.perl.misc:
> In researching the Perl fork() command,
Did that research include reading "perldoc -f fork"? That would
be the starting point of any research.
> I've come across many examples
> of code and have been able to ascertain that when fork() is called,
> the parent process retains it's own PID
correct, so far.
> wil the child process takes a
> PID of 0, at least in relation to the parent process.
Where did you get that? The child gets its own PID, which fork
returns to the parent. fork() returns 0 to the child (that's how the
code can *tell* it is the child code). Otherwise, the child can
access its own pid via $$, it doesn't have to be told by fork().
There is no such thing as one PID "in relation" to another. PIDs
are integers, which are system-wide unique at any time, that's
their purpose.
> This is pretty simple to see and understand, except for the
> understanding that the process invoking fork() creates a clone of
> itself, in which case the code examples I see leave one thing
> unexplained. Take for instance the basic fork() routine similar to
> what I've found on the web:
>
> $pid = fork();
>
> if ($pid == 0) {
> # Then I'm the child process
> } else {
> # I'm the parent process
> }
>
> Programmatically correct considerations aside (I know I should include
> an exit for the child process), I'm wondering--if the child process is
> a clone of the parent--why the child process doesn't execute the "$pid
> = fork()" statement.
Because there is no child process when fork() is executed. The
parent process runs it for both. fork() *returns* twice, once to
the parent and once to the child, with different return values.
> Is there some limitation to the amount of code
> that gets "cloned"?
No, everything is cloned, but so is the point of execution. That
it, both continue immediately after fork() returns. Then they must
decide who is who.
> Secondly, I see a code snippet out there that confuses me and I'd just
> like clarification of what it's saying. The following line:
>
> unless ($pid = fork()) {
> # Do something as the child process
> }
>
> 'unless' is, as I understand it, used to loop when a condition is
> false. False, in Perl, is the value 0 (along with undef and the empty
> string). What is this the result of this fork() and it's effect on
> the 'unless' statement? If the fork() produces a child process, then
> doesn't the result of the entire '$pid = fork()' statement produce a
> true value, as in the call to fork() executed correctly? If it did,
> then doesn't the 'unless' statement test as true, meaning the loop
> code gets bypassed?
I think something is wrong about your mental model of what happens
with fork(). If my comments above (firstly) plus the lecture of
"perldoc -f fork" (mostly) don't help you set it right, I wouldn't
know what else to say. If they do help you understand fork(), I
think you will be able to answer the questions in the last
paragraph yourself.
Anno
------------------------------
Date: Wed, 21 Feb 2007 13:00:28 -0800
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: fork()-ing questions
Message-Id: <210220071300286270%jgibson@mail.arc.nasa.gov>
In article <1172090025.578027.306150@j27g2000cwj.googlegroups.com>,
Monty <dale.schmitz@offutt.af.mil> wrote:
[program using fork snipped]
> My second question is still foggy, and I may not have asked it
> correctly. Considering the statment 'unless ($pid = fork())', if the
> fork is successful, then the entire '$pid = fork()' statement is
> evaluated as true and the loop code gets skipped--which is ok in the
> parent process. Then, if the perldoc is to be taken at its word, the
> child process that gets forked only consists of the code following the
> fork() statement, which in this case is the loop code. I see the
> benefit of coding exits in child process code.
>
> How am I doing so far?
You seem not to grasp that the call to fork(), if successful, will
return two values: one to the parent and one the child. The parent
value will be non-zero and therefore true, but the child's value will
be zero and false. Therefore, the code in the unless block will be only
executed by the child. Also, "unless" does not start a loop (you may be
thinking of "until"). It is a one-time conditional, equivalent to "if
not".
The "child code" consists of everything inside the "unless" block, plus
everything that follows that block unless and until the child executes
an exit. The "child code" is the _same_ as the "parent code". It is up
to your program to make each of them behave in an appropriate manner,
using the return value from fork() to distinguish between them.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
Date: Wed, 21 Feb 2007 14:50:04 -0500
From: RC <raymond.chui@nospam.noaa.gov>
Subject: Re: Mystry CGI Perl from new Redhat server
Message-Id: <eri7pf$asj$1@news.nems.noaa.gov>
Joe Smith wrote:
>
> Insufficient information.
OK
>
> 1) You neglected to tell us which version of RedHat and perl. `uname
> -a;perl -V`
My old OS was Redhat updae 3, the new OS is Redhat update 4
They are both running Perl 5.8.5
>
> 2) Sounds like you haven't even bothered looking at the webserver's
> error log: /var/log/httpd/error_log
That file dosen't help too much to resolve my problem
(only tittle help).
Oh, well. Do you want to know what is the problem?
The problem is neither Perl nor Redhat OS issue, it is PostgreSQL
(database) issue. The old OS Redhat update 3 is running PostgreSQL
7.3, the new OS Redhat update 4 is running PostgreSQL 7.4.
The Perl DBI (database interface?) is not compatible, cause my Perl DBI
file Segmentation fault. I have to do some minor modification in my file
to resolved the problem.
------------------------------
Date: 21 Feb 2007 12:26:49 -0800
From: joakim.grahl@gmail.com
Subject: Re: Passing an array of arrays to an external function
Message-Id: <1172089608.951316.292140@q2g2000cwa.googlegroups.com>
Figured it out :)
When push-ing to @plots, the first entry was always NULL, and this
crashed Gnuplot...
Fixing this, and the generic call, gnuplot(\%options, @plots), worked
fine every time :)
------------------------------
Date: 21 Feb 2007 12:22:51 -0800
From: skyn3t@gmail.com
Subject: perl CPU utilization and socket I/O
Message-Id: <1172089371.682916.184090@t69g2000cwt.googlegroups.com>
I have a perl cgi script that reads from the network and outputs about
40K per second to the caller.
The script is averaging about 15-25% CPU utilization, when it isn't
doing much other than reading from the network, parsing the message,
and printing it. I want to get this CPU utilization down.
Things I have tried:
(1) Use SmallProf/DProf to get profiling information on the script and
make adjustments. I made quite a few perl optimizations based on this
data and it barely dented the CPU utilization.
(2) Convert the script to use sysread() to read the data in larger
chunks than the perlio libs do. This did not change the CPU
utilization at all.
(3) Select on the socket before attempting reading from it, and bail
if there is no data. Didn't help CPU.
So what's causing it? I'm stumped.
Here is what a 2 minute "time" call to my script looks like:
real 2m8.469s
user 0m1.557s
sys 0m0.795s
Should I be worried about the large discrepancy between the real time
and the user+sys time? This indicates that perl is idling quite a bit,
correct? Is this normal for a perl application?
Any thoughts on how I can determine where the CPU utilization is
coming from?
------------------------------
Date: 21 Feb 2007 12:06:46 -0800
From: "marie" <mariecuddy@gmail.com>
Subject: Running Java file and capturing output
Message-Id: <1172088406.621502.19940@l53g2000cwa.googlegroups.com>
Hi,
I need to call a Java class and capture the output it generates and
send it to a file.
I tried using the system command:
system("/usr/local/bin/java, </var/log/MyJavaClass', &> /var/tmp/
history.html");
However i get the following error:
sh: /var/log/MyJavaClass, &> /var/tmp/history.html: cannot open
Does anyone know what I am doing wrong?
I am running this script from Unix,
Marie
------------------------------
Date: Wed, 21 Feb 2007 13:05:55 -0800
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: Running Java file and capturing output
Message-Id: <210220071305555903%jgibson@mail.arc.nasa.gov>
In article <1172088406.621502.19940@l53g2000cwa.googlegroups.com>,
marie <mariecuddy@gmail.com> wrote:
> Hi,
>
> I need to call a Java class and capture the output it generates and
> send it to a file.
> I tried using the system command:
>
> system("/usr/local/bin/java, </var/log/MyJavaClass', &> /var/tmp/
> history.html");
>
> However i get the following error:
> sh: /var/log/MyJavaClass, &> /var/tmp/history.html: cannot open
>
> Does anyone know what I am doing wrong?
Yes. You are confusing the two forms of the system command. One uses a
single string argument that contains a command and command-line
arguments, the other a list of arguments. The latter needs an array or
a comma-separated list; the former does not.
Try entering the command just the way you would to a shell prompt,
omitting the commas:
system("/usr/local/bin/java </var/log/MyJavaClass' &>
/var/tmp/history.html");
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
Date: Wed, 21 Feb 2007 13:51:12 -0600
From: Jeremy Henty <jeremy@chaos.org.uk>
Subject: Re: Subclassing CGI::Pretty dies instantly in ->new , bug?
Message-Id: <slrnetp8k5.4er.jeremy@omphalos.onepoint>
On 2007-02-21, Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "JH" == Jeremy Henty <jeremy@chaos.org.uk> writes:
>
> JH> I created a subclass of CGI::Pretty and it instantly dies:
> JH> $ /data/www-jeremy/cgi-bin/cgi-jeremy
> JH> Undefined subroutine Jeremy::CGI::delete
> JH> at /data/www-jeremy/cgi-bin/cgi-jeremy line 9
>
> JH> Line 9 is:
>
> JH> my $query = Jeremy::CGI->new;
>
> JH> If I modify the class to inherit from CGI then it works.
>
> you are contradicting yourself. you can't subclass without
> inheriting.
I don't see how this comment relates to my problem. I'm not claiming
you can subclass without inheriting. What I have is two modules,
identical except that one subclasses CGI and the other subclasses
CGI::Pretty , and the first works and the second breaks. What is
wrong with trying to subclass CGI::Pretty ?
> ...the namespace of a module HAS NOTHING to do with subclassing or
> inheritance. it is an arbitrary namespace and you can call it Foo
> and subclass Bar.
I'm aware of that. I've actually written code that does that without
problems. It doesn't explain why my module breaks if I replace "use
CGI;" with "use CGI::Pretty;" and "@ISA = qw( CGI );" with "@ISA = qw(
CGI::Pretty );". I've read the CGI and CGI::Pretty perldocs, Googled
and searched perl.doc and found nothing that explains this.
> JH> use CGI;
> JH> our @ISA;
> JH> @ISA = qw( CGI );
>
> replace all that with:
>
> use base 'CGI' ;
Thanks for the tip but it doesn't help the original problem, "use base
'CGI';" works fine and "use base 'CGI::Pretty';" dies exactly as
before. So I'm still mystified.
Regards,
Jeremy Henty
------------------------------
Date: Wed, 21 Feb 2007 14:06:55 -0600
From: Jeremy Henty <jeremy@chaos.org.uk>
Subject: Re: Subclassing CGI::Pretty dies instantly in ->new , bug?
Message-Id: <slrnetp9hl.4er.jeremy@omphalos.onepoint>
On 2007-02-21, Jeremy Henty <jeremy@chaos.org.uk> wrote:
> ... What I have is two modules, identical except that one
> subclasses CGI and the other subclasses CGI::Pretty , and the first
> works and the second breaks. What is wrong with trying to subclass
> CGI::Pretty ?
I'm following up to myself to explain further: the reason why this is
so surprising is that CGI::Pretty is just a subclass of CGI that
modifies a few methods to produce nicer HTML output. If I rewrite my
CGI script to use CGI::Pretty directly then it works.
So the *real* puzzle is this: why does replacing CGI::Pretty with a
module that does nothing except inherit from CGI::Pretty break things?
In fact "perldoc perltoot" says:
Setting up an empty class like this is called the "empty subclass
test"; that is, making a derived class that does nothing but
inherit from a base class. If the original base class has been
designed properly, then the new derived class can be used as a
drop-in replacement for the old one.
which suggests that CGI::Pretty is actually broken since it fails the
empty subclass test. If that's so then at the very least the docs
should say so.
Hope this clarifies my question.
Regards,
Jeremy Henty
------------------------------
Date: Wed, 21 Feb 2007 16:05:48 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Subclassing CGI::Pretty dies instantly in ->new , bug?
Message-Id: <x77iubmdar.fsf@mail.sysarch.com>
>>>>> "JH" == Jeremy Henty <jeremy@chaos.org.uk> writes:
JH> On 2007-02-21, Jeremy Henty <jeremy@chaos.org.uk> wrote:
>> ... What I have is two modules, identical except that one
>> subclasses CGI and the other subclasses CGI::Pretty , and the first
>> works and the second breaks. What is wrong with trying to subclass
>> CGI::Pretty ?
JH> I'm following up to myself to explain further: the reason why this is
JH> so surprising is that CGI::Pretty is just a subclass of CGI that
JH> modifies a few methods to produce nicer HTML output. If I rewrite my
JH> CGI script to use CGI::Pretty directly then it works.
well, for one thing since you don't seem to do anything special in
Jeremy::CGI why do you need that module?
the error you get seems to imply a broken inheritance path as your new
method is calling a delete method up the @ISA tree. when you changed
your module to use CGI::Pretty did you change all the CGI to
CGI::Pretty? you didn't show that version.
JH> So the *real* puzzle is this: why does replacing CGI::Pretty with a
JH> module that does nothing except inherit from CGI::Pretty break things?
i looked at the code and it seems it should work so i will bet it is
your code that is somehow broken. nothing personal but that is a good
bet when someone complains about modules by certain authors such as
lincoln stein.
try using the use base idea i mentioned. it does exactly what you want
and it means only one place needs to be changed from CGI to
CGI::Pretty. maybe that will fix it or help isolate the problem.
also to make your life easier for testing you can run this directly and
not under a web server. this is much better for debugging many cgi
scripts in general.
if you think (and can prove) this is a real error in CGI::Pretty then
you should report it to the author (but not until you can show serious
evidence on your side).
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.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 V11 Issue 159
**************************************
