[23044] in Perl-Users-Digest
Perl-Users Digest, Issue: 5265 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jul 24 03:05:46 2003
Date: Thu, 24 Jul 2003 00:05:09 -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 Thu, 24 Jul 2003 Volume: 10 Number: 5265
Today's topics:
Re: Authentication with LWP <jwillmore@cyberia.com>
Re: Called as method or subroutine? <mgjv@tradingpost.com.au>
Re: Called as method or subroutine? <tassilo.parseval@rwth-aachen.de>
Re: CGI.pm problem under Redhat Linux 9.0 (perl-5.8.0) <jwillmore@cyberia.com>
Re: CGI.pm problem under Redhat Linux 9.0 (perl-5.8.0) <jwillmore@cyberia.com>
Re: Chomp temporarily nullifies my scalar variable. <jandellis@hotmail.com>
Re: Chomp temporarily nullifies my scalar variable. <grazz@pobox.com>
Re: Chomp temporarily nullifies my scalar variable. (Sam Holden)
Re: Chomp temporarily nullifies my scalar variable. <kkeller-spammmm@wombat.san-francisco.ca.us>
Re: Chomp temporarily nullifies my scalar variable. <jandellis@hotmail.com>
Re: Chomp temporarily nullifies my scalar variable. <jandellis@hotmail.com>
Re: Chomp temporarily nullifies my scalar variable. <jandellis@hotmail.com>
Re: Chomp temporarily nullifies my scalar variable. <tassilo.parseval@rwth-aachen.de>
Install Perl Bin on Win32 Using Mingw (GCC) <mattogan@verizon.net>
Re: Install Perl Bin on Win32 Using Mingw (GCC) <kalinabears@iinet.net.au>
Re: Larry W... out of work ?? Impossible... or... (Randal L. Schwartz)
simple web site mapper <jidanni@jidanni.org>
Re: size of graphics files.... <mgjv@tradingpost.com.au>
Re: Style question regarding subroutines and lexical va <jandellis@hotmail.com>
Re: <bwalton@rochester.rr.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 24 Jul 2003 04:49:36 GMT
From: James Willmore <jwillmore@cyberia.com>
Subject: Re: Authentication with LWP
Message-Id: <20030724005054.5946e9c6.jwillmore@cyberia.com>
> My first question is, how to get the correct realm, because I am
> aware that 'Client login' is not accurate.
>
> And my second quesiton is, when I do have the correct realm, how do
> I use browser-credentials correctly to get the information I want.
> If I left anything out, please let me know, by private email or
> follow-up posts. Thanks in advance for your help.
I'm not 100% sure, but you may need to use LWP::AuthenAgent versus
straight LWP.
try
http://search.cpan.org/author/AWRIGLEY/sitemapper-1.019/lib/LWP/AuthenAgent.pm
for more info.
HTH
Jim
------------------------------
Date: 24 Jul 2003 05:23:09 GMT
From: Martien Verbruggen <mgjv@tradingpost.com.au>
Subject: Re: Called as method or subroutine?
Message-Id: <slrnbhur9v.1le.mgjv@verbruggen.comdyn.com.au>
On Wed, 23 Jul 2003 21:51:23 -0500,
Eric J. Roode <REMOVEsdnCAPS@comcast.net> wrote:
>
> ed <coo_t2-NO-LIKE-SPAM@yahoo.com> wrote in
> news:gk7uhvstvnnct0e73big7muhujl3h7jte9@4ax.com:
>
>> Hi is there a way to make a sub/method compatible with
>> the two following calling methods?
>>
>> 1. MyClass::mySub();
>> 2. MyClass->mySub();
>>
>> Using the first method gives me one less argument in my argument list.
>> How do you deal with both situations?
>> Is there an easy way to find out if you're being invoked a method or
>> subroutine?
>
> Well, you could check the first argument and see if it's equal to
> __PACKAGE__. But that's not a good solution, because it breaks
> inheritance.
The notation MyClass::mySub() is not subject to inheritance in any
way. In other words, the above two calls cannot be equivalent, because
of Perl's magical treatment of that arrow. If you use that arrow, Perl
will search through @ISA. If you don't, then it won't.
The only way in which these two calls can ever be reasonably the same
is if the first argument were ignored when it's called as
MyClass->mySub(), and that can be done by simply discarding the first
argument when it's equal to __PACKAGE__.
sub MyClass::mySub
{
shift if $_[0] eq __PACKAGE__;
# do stuff...
}
Of course, if someone does:
MyClass::mySub("MyClass");
and expect that that argument won't get discarded, they will get a
nasty surprise.
I'd agree with Eric that it's a bad idea. it's misleading to call
something that can only be a regular sub with the arrow notation,
which strongly hints at class method implementation details. If you
really want this method to act as a class method, then you should
not call it without the arrow notation. Perl will not look for the
method in any superclasses unless you use that arrow, and if you
always need to call it with the arrow, then you don't need them to be
"equivalent".
Martien
--
|
Martien Verbruggen | Failure is not an option. It comes bundled
Trading Post Australia | with your Microsoft product.
|
------------------------------
Date: 24 Jul 2003 06:21:58 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: Called as method or subroutine?
Message-Id: <bfntu6$7pj$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Martien Verbruggen:
> On Wed, 23 Jul 2003 21:51:23 -0500,
> Eric J. Roode <REMOVEsdnCAPS@comcast.net> wrote:
>>
>> ed <coo_t2-NO-LIKE-SPAM@yahoo.com> wrote in
>> news:gk7uhvstvnnct0e73big7muhujl3h7jte9@4ax.com:
>>
>>> Hi is there a way to make a sub/method compatible with
>>> the two following calling methods?
>>>
>>> 1. MyClass::mySub();
>>> 2. MyClass->mySub();
>>>
>>> Using the first method gives me one less argument in my argument list.
>>> How do you deal with both situations?
>>> Is there an easy way to find out if you're being invoked a method or
>>> subroutine?
>>
>> Well, you could check the first argument and see if it's equal to
>> __PACKAGE__. But that's not a good solution, because it breaks
>> inheritance.
>
> The notation MyClass::mySub() is not subject to inheritance in any
> way. In other words, the above two calls cannot be equivalent, because
> of Perl's magical treatment of that arrow. If you use that arrow, Perl
> will search through @ISA. If you don't, then it won't.
Which, as far as I understand, was Eric's point. The comparison with
__PACKAGE__ should not be done in a class-method because otherwise the
package of this method cannot be used as a superclass. This distinction
between class-method and plain function (or lack thereof) is one of the
true Perl-oddities. CGI.pm fell into this trap:
ethan@ethan:~$ perl -lMCGI=b1
print CGI->b1("CGI");
print b1("CGI");
print b1("cgi");
<b1>CGI</b1>
<b1></b1>
<b1>cgi</b1>
Lincoln fixed that in the latest release, though.
> The only way in which these two calls can ever be reasonably the same
> is if the first argument were ignored when it's called as
> MyClass->mySub(), and that can be done by simply discarding the first
> argument when it's equal to __PACKAGE__.
>
> sub MyClass::mySub
> {
> shift if $_[0] eq __PACKAGE__;
> # do stuff...
> }
>
> Of course, if someone does:
>
> MyClass::mySub("MyClass");
>
> and expect that that argument won't get discarded, they will get a
> nasty surprise.
Yes, as the above CGI-bug shows.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Thu, 24 Jul 2003 05:06:38 GMT
From: James Willmore <jwillmore@cyberia.com>
Subject: Re: CGI.pm problem under Redhat Linux 9.0 (perl-5.8.0)
Message-Id: <20030724010627.47a1cb7b.jwillmore@cyberia.com>
> use CGI /:standard/;
try:
use CGI qw/:standard/;
Looks like you forgot the qw
> I went to perl directory: /usr/lib/perl5/5.8.0. There is no CGI.pm,
> but there is a CGI.pm.newcgi. What should I do? rename this
> CGI.pm.newcgi to CGI.pm? that sounds weird ...
'.pm' files are going to be located, typically, in your @INC
directories, so you won't see it in the place you were looking. But,
if you REALLY want to find the exact location of the file, type:
perldoc -l CGI
HTH
Jim
------------------------------
Date: Thu, 24 Jul 2003 05:14:13 GMT
From: James Willmore <jwillmore@cyberia.com>
Subject: Re: CGI.pm problem under Redhat Linux 9.0 (perl-5.8.0)
Message-Id: <20030724011242.554b18c5.jwillmore@cyberia.com>
> use CGI /:standard/;
try:
use CGI qw/:standard/;
Looks like you forgot the qw
> I went to perl directory: /usr/lib/perl5/5.8.0. There is no CGI.pm,
> but there is a CGI.pm.newcgi. What should I do? rename this
> CGI.pm.newcgi to CGI.pm? that sounds weird ...
'.pm' files are going to be located, typically, in your @INC
directories, so you won't see it in the place you were looking. But,
if you REALLY want to find the exact location of the file, type:
perldoc -l CGI
HTH
Jim
------------------------------
Date: Thu, 24 Jul 2003 04:14:55 GMT
From: Joseph Ellis <jandellis@hotmail.com>
Subject: Re: Chomp temporarily nullifies my scalar variable.
Message-Id: <v6muhv0ifmv5rr73ahr8epokj8trdr2c0k@4ax.com>
On Thu, 24 Jul 2003 03:35:53 GMT, Bob Walton
<bwalton@rochester.rr.com> wrote:
>Joseph Ellis wrote:
>
>> I am writing a program / script (in Perl, yet) that will parse a text
>> database of genealogy information to generate a web-based family tree.
>> When invoking the script, I have to give it an ID such as "I108" to
>> search for. Development has been going fine so far, but since I often
>> forget to specify an ID, I'm making a little if {} block to allow me
>> to type in an ID when I forget to do so at invocation:
>>
>> #!/usr/bin/perl
>>
>> use strict;
>> use warnings;
>> use CGI ':standard';
>> use CGI::Carp qw(fatalsToBrowser);
>>
>> my $gedcom="Joseph Ellis Family.ged";
>> my $id = param('id');
>>
>> if (not $id) { ## Just because I keep forgetting to specify the ID
>> print ("\n\nSpecify an ID to work with.\n: ");
>> chomp ($id = <STDIN>);
>
>
>You are running a CGI script. STDIN is therefore either hooked up to
>the output of your web browser (POST mode) or not hooked to anything
>(GET mode), and STDOUT is hooked to your browser.
Indeed, this program is intended to be a CGI script when it is
finished. But for the sake of development I'm running the script from
the command line (Windows XP - C:\Perl\bin\perl pgd.pl). When that
time comes $id will be passed to the script as a param when the user
clicks on a person's name in the family tree. The script will then
look up that person in the GEDCOM ASCII file and display corresponding
info in HTML. Until that time, I'm testing the script via the command
line.
>It won't give you a
>prompt and permit you to input on your browser if that is what you were
>hoping for (although it will print the prompt message on your browser).
> Nor will it give you a console window with the prompt in it. Your
>best bet is to generate an error page with a "back" link explaining what
>happened and how to fix it.
>
>But I'm confused -- you neglected to print an HTTP header, so you should
>get a 500 error from this. Are you just running the script standalone
>at the moment?
Yes.
>If so, you should be prepared for this not to work when
>you try it as a CGI.
I will create appropriate HTML interfaces when the time comes. I was
not asking about the CGI aspect of my script, nor was I curious about
its potential success or failure as a CGI script. At this stage,
modifying the script's output to be HTTP / HTML compliant is
irrelevant.
>
>I don't have an explanation for the remainder of the behavior you
>describe. It doesn't do that on my system (Windoze 98SE, AS build 806)
>-- I get the expected output. And it should work properly on any
>platform I know of.
Thanks for your input.
>> Joseph
------------------------------
Date: Thu, 24 Jul 2003 04:22:11 GMT
From: Steve Grazzini <grazz@pobox.com>
Subject: Re: Chomp temporarily nullifies my scalar variable.
Message-Id: <T9JTa.22340$0F4.14868@nwrdny02.gnilink.net>
Joseph Ellis <jandellis@hotmail.com> wrote:
> Steve Grazzini <grazz@pobox.com> wrote:
> >It looks like you read $id = "ID\r\n" and chomp() only removed
> >the newline.
>
> Yes, you're right. Putting $id =~ s/\r//; after the chomp statement
> fixed the problem.
>
> But in a fit of raging curiosity, I've done the following:
>
> if (not $id) { ## Just because I keep forgetting to specify the ID
> print ("\n\nSpecify an ID to work with.\n: ");
> chomp ($id = <STDIN>);
> print "Is there a carriage return following the ID? $id\n";
> print "Is there a carriage return $id following the ID?\n";
> exit;
> }
>
> This outputs:
>
> Is there a carriage return following the ID? I108
> following the ID?e return I108
>
> Any idea why the first line printed "properly", and the second line
> printed "improperly"?
That's what a carriage return *does*. :-)
(The last half of the line has overwritten the first.)
What puzzled me was why the "\r" was there in the first place,
but I guess CGI.pm has done "binmode STDIN".
--
Steve
------------------------------
Date: 24 Jul 2003 04:30:09 GMT
From: sholden@flexal.cs.usyd.edu.au (Sam Holden)
Subject: Re: Chomp temporarily nullifies my scalar variable.
Message-Id: <slrnbhuo6h.khk.sholden@flexal.cs.usyd.edu.au>
On Thu, 24 Jul 2003 04:14:55 GMT, Joseph Ellis <jandellis@hotmail.com> wrote:
> On Thu, 24 Jul 2003 03:35:53 GMT, Bob Walton
><bwalton@rochester.rr.com> wrote:
>
>>Joseph Ellis wrote:
>>
>>> I am writing a program / script (in Perl, yet) that will parse a text
>>> database of genealogy information to generate a web-based family tree.
>>> When invoking the script, I have to give it an ID such as "I108" to
>>> search for. Development has been going fine so far, but since I often
>>> forget to specify an ID, I'm making a little if {} block to allow me
>>> to type in an ID when I forget to do so at invocation:
>>>
>>> #!/usr/bin/perl
>>>
>>> use strict;
>>> use warnings;
>>> use CGI ':standard';
>>> use CGI::Carp qw(fatalsToBrowser);
>>>
>>> my $gedcom="Joseph Ellis Family.ged";
>>> my $id = param('id');
>>>
>>> if (not $id) { ## Just because I keep forgetting to specify the ID
>>> print ("\n\nSpecify an ID to work with.\n: ");
>>> chomp ($id = <STDIN>);
>>
>>
>>You are running a CGI script. STDIN is therefore either hooked up to
>>the output of your web browser (POST mode) or not hooked to anything
>>(GET mode), and STDOUT is hooked to your browser.
>
> Indeed, this program is intended to be a CGI script when it is
> finished. But for the sake of development I'm running the script from
> the command line (Windows XP - C:\Perl\bin\perl pgd.pl). When that
> time comes $id will be passed to the script as a param when the user
> clicks on a person's name in the family tree. The script will then
> look up that person in the GEDCOM ASCII file and display corresponding
> info in HTML. Until that time, I'm testing the script via the command
> line.
CGI.pm has a debugging mode selected with '-debug', so in your case:
use CGI qw(:standard -debug);
That causes the script to prompt for name=value pairs on STDIN, which
you terminate with EOF (ctrl-Z on a new line under Windows).
By using it you won't get hit with "non-bugs" such as this, which
are in the code which won't be used when the script is run as a
CGI.
See the CGI module documentation for more information.
--
Sam Holden
------------------------------
Date: Wed, 23 Jul 2003 21:28:09 -0700
From: Keith Keller <kkeller-spammmm@wombat.san-francisco.ca.us>
Subject: Re: Chomp temporarily nullifies my scalar variable.
Message-Id: <p8nnfb.k94.ln@goaway.wombat.san-francisco.ca.us>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
In article <ptjuhvsha864rfjofkc1nv7tu6sj190te2@4ax.com>, Joseph Ellis wrote:
> Yes, you're right. Putting $id =~ s/\r//; after the chomp statement
> fixed the problem.
>
> But in a fit of raging curiosity, I've done the following:
>
> if (not $id) { ## Just because I keep forgetting to specify the ID
> print ("\n\nSpecify an ID to work with.\n: ");
> chomp ($id = <STDIN>);
> print "Is there a carriage return following the ID? $id\n";
> print "Is there a carriage return $id following the ID?\n";
> exit;
> }
>
> This outputs:
>
> Is there a carriage return following the ID? I108
> following the ID?e return I108
>
> Any idea why the first line printed "properly", and the second line
> printed "improperly"?
Because the second line printed the string
"Is there a carriage return I108\r following the ID?\n"
interpreting the \r meaning 'move to the beginning of the line',
just like a typewriter would. Neat trick, eh? If you strip
the \r character it should print as you expect.
You mentioned that this will be a CGI script for which you
haven't printed HTML yet, but as has been pointed out, that
if statement will be problematic if no id key is provided
in the GET or POST request. Your previous message in this
thread didn't make clear whether you understood the implications
of STDIN in a CGI context or not. (In any case, we're starting
to talk CGI, not Perl, which is a different newsgroup.)
- --keith
- --
kkeller-mmmspam@wombat.san-francisco.ca.us
(try just my userid to email me)
alt.os.linux.slackware FAQ: http://wombat.san-francisco.ca.us/cgi-bin/fom
-----BEGIN xxx SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAj8fYFIACgkQhVcNCxZ5ID9arwCgkJt0r6drBKPshEvW6UB0jA44
sxMAniRmnSd+pdCXdfZE0NVe3ymzzIVa
=aR+2
-----END PGP SIGNATURE-----
------------------------------
Date: Thu, 24 Jul 2003 04:39:34 GMT
From: Joseph Ellis <jandellis@hotmail.com>
Subject: Re: Chomp temporarily nullifies my scalar variable.
Message-Id: <pcouhv8nrek1llhqcress51t9urkmt7038@4ax.com>
On Thu, 24 Jul 2003 04:22:11 GMT, Steve Grazzini <grazz@pobox.com>
wrote:
>Joseph Ellis <jandellis@hotmail.com> wrote:
>> Steve Grazzini <grazz@pobox.com> wrote:
>> >It looks like you read $id = "ID\r\n" and chomp() only removed
>> >the newline.
>>
>> Yes, you're right. Putting $id =~ s/\r//; after the chomp statement
>> fixed the problem.
>>
>> But in a fit of raging curiosity, I've done the following:
>>
>> if (not $id) { ## Just because I keep forgetting to specify the ID
>> print ("\n\nSpecify an ID to work with.\n: ");
>> chomp ($id = <STDIN>);
>> print "Is there a carriage return following the ID? $id\n";
>> print "Is there a carriage return $id following the ID?\n";
>> exit;
>> }
>>
>> This outputs:
>>
>> Is there a carriage return following the ID? I108
>> following the ID?e return I108
>>
>> Any idea why the first line printed "properly", and the second line
>> printed "improperly"?
>
>That's what a carriage return *does*. :-)
Ahh. I see...very interesting...it's all so clear now :)
>(The last half of the line has overwritten the first.)
Uh huh.
>
>What puzzled me was why the "\r" was there in the first place,
It puzzled me as well.
>but I guess CGI.pm has done "binmode STDIN".
Um, ok. I don't know what that means, but remarking out CGI.pm did
the trick. Both lines print as expected. Can you elaborate on the
"binmode STDIN" bit, or tell me where I can learn more about it?
Thanks fer yer thoughts.
Joseph
------------------------------
Date: Thu, 24 Jul 2003 04:51:44 GMT
From: Joseph Ellis <jandellis@hotmail.com>
Subject: Re: Chomp temporarily nullifies my scalar variable.
Message-Id: <bpouhv4c463eplbchmvk63i63uokhi9l4a@4ax.com>
On Wed, 23 Jul 2003 21:28:09 -0700, Keith Keller
<kkeller-spammmm@wombat.san-francisco.ca.us> wrote:
>-----BEGIN xxx SIGNED MESSAGE-----
>Hash: SHA1
>
>In article <ptjuhvsha864rfjofkc1nv7tu6sj190te2@4ax.com>, Joseph Ellis wrote:
>
>> Yes, you're right. Putting $id =~ s/\r//; after the chomp statement
>> fixed the problem.
>>
>> But in a fit of raging curiosity, I've done the following:
>>
>> if (not $id) { ## Just because I keep forgetting to specify the ID
>> print ("\n\nSpecify an ID to work with.\n: ");
>> chomp ($id = <STDIN>);
>> print "Is there a carriage return following the ID? $id\n";
>> print "Is there a carriage return $id following the ID?\n";
>> exit;
>> }
>>
>> This outputs:
>>
>> Is there a carriage return following the ID? I108
>> following the ID?e return I108
>>
>> Any idea why the first line printed "properly", and the second line
>> printed "improperly"?
>
>Because the second line printed the string
>
> "Is there a carriage return I108\r following the ID?\n"
>
>interpreting the \r meaning 'move to the beginning of the line',
>just like a typewriter would. Neat trick, eh? If you strip
>the \r character it should print as you expect.
Yes. s/\r// does the trick.
>
>You mentioned that this will be a CGI script for which you
>haven't printed HTML yet, but as has been pointed out, that
>if statement will be problematic if no id key is provided
>in the GET or POST request. Your previous message in this
>thread didn't make clear whether you understood the implications
>of STDIN in a CGI context or not. (In any case, we're starting
>to talk CGI, not Perl, which is a different newsgroup.)
Ahh. I suppose I didn't make that clear. Currently I'm testing the
script from the DOS-esque command line. But I sometimes / often
forget to specify the desired id on the command line at invocation (as
in id=I108), so I decided to throw in this little if statement.
When I get to the point of "porting" (if you want to call it that) the
script to CGI world, I'll remove the if statement. I only put it
there because each time I ran the script without providing any
arguments it got stuck in an endless loop further on down the line,
and I was getting quite annoyed with myself for chronically forgetting
to provide the argument. Then the chomp thing confused me and voila -
this thread was born.
>
>- --keith
Joseph
------------------------------
Date: Thu, 24 Jul 2003 04:53:08 GMT
From: Joseph Ellis <jandellis@hotmail.com>
Subject: Re: Chomp temporarily nullifies my scalar variable.
Message-Id: <9hpuhv0a3unlrbqs9cp2bj0nufo0pcb668@4ax.com>
On 24 Jul 2003 04:30:09 GMT, sholden@flexal.cs.usyd.edu.au (Sam
Holden) wrote:
>On Thu, 24 Jul 2003 04:14:55 GMT, Joseph Ellis <jandellis@hotmail.com> wrote:
>> On Thu, 24 Jul 2003 03:35:53 GMT, Bob Walton
>><bwalton@rochester.rr.com> wrote:
>>
>>>Joseph Ellis wrote:
>>>
>>>> I am writing a program / script (in Perl, yet) that will parse a text
>>>> database of genealogy information to generate a web-based family tree.
>>>> When invoking the script, I have to give it an ID such as "I108" to
>>>> search for. Development has been going fine so far, but since I often
>>>> forget to specify an ID, I'm making a little if {} block to allow me
>>>> to type in an ID when I forget to do so at invocation:
>>>>
>>>> #!/usr/bin/perl
>>>>
>>>> use strict;
>>>> use warnings;
>>>> use CGI ':standard';
>>>> use CGI::Carp qw(fatalsToBrowser);
>>>>
>>>> my $gedcom="Joseph Ellis Family.ged";
>>>> my $id = param('id');
>>>>
>>>> if (not $id) { ## Just because I keep forgetting to specify the ID
>>>> print ("\n\nSpecify an ID to work with.\n: ");
>>>> chomp ($id = <STDIN>);
>>>
>>>
>>>You are running a CGI script. STDIN is therefore either hooked up to
>>>the output of your web browser (POST mode) or not hooked to anything
>>>(GET mode), and STDOUT is hooked to your browser.
>>
>> Indeed, this program is intended to be a CGI script when it is
>> finished. But for the sake of development I'm running the script from
>> the command line (Windows XP - C:\Perl\bin\perl pgd.pl). When that
>> time comes $id will be passed to the script as a param when the user
>> clicks on a person's name in the family tree. The script will then
>> look up that person in the GEDCOM ASCII file and display corresponding
>> info in HTML. Until that time, I'm testing the script via the command
>> line.
>
>CGI.pm has a debugging mode selected with '-debug', so in your case:
>
>use CGI qw(:standard -debug);
>
>That causes the script to prompt for name=value pairs on STDIN, which
>you terminate with EOF (ctrl-Z on a new line under Windows).
>
>By using it you won't get hit with "non-bugs" such as this, which
>are in the code which won't be used when the script is run as a
>CGI.
>
>See the CGI module documentation for more information.
Thank you very much. I'll do that.
Joseph
------------------------------
Date: 24 Jul 2003 06:35:44 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: Chomp temporarily nullifies my scalar variable.
Message-Id: <bfnuo0$8gh$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Joseph Ellis:
> On Thu, 24 Jul 2003 04:22:11 GMT, Steve Grazzini <grazz@pobox.com>
> wrote:
>>What puzzled me was why the "\r" was there in the first place,
>
> It puzzled me as well.
>
>>but I guess CGI.pm has done "binmode STDIN".
>
> Um, ok. I don't know what that means, but remarking out CGI.pm did
> the trick. Both lines print as expected. Can you elaborate on the
> "binmode STDIN" bit, or tell me where I can learn more about it?
See 'perldoc -f binmode'. It has something to do with how perl treats
characters. It used to be related to newlines mainly, but nowadays in
times of Unicode, this is no longer true (recent RedHats have gain some
fame in that they might require binmode() in their default configuration
as well).
On Windows, the newline is represented by the two bytes \015\012, on
most other platforms it is only one byte (unices usually \012,
Macintoshs \015). So if you do not binmode a filehandle and read from it
linewise on Windows, perl translates \015\012 to \012. Since this is the
value of $/ (the $INPUT_RECORD_SEPARATOR that for instance chomp() uses
as default-character to strip), chomp() later does the right thing.
However, if you binmode() your filehandle, this translation does not
happen, so chomp() still removes the \012 but the carriage-return
character still exists so it turnes instances of \015\012 into \015.
If you have ever used FTP, think of binmode() as the equivalent to
binary transfer-mode, whereas the default (no binmode()) is text-mode.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Thu, 24 Jul 2003 04:07:32 GMT
From: "Matthew Ogan" <mattogan@verizon.net>
Subject: Install Perl Bin on Win32 Using Mingw (GCC)
Message-Id: <8YITa.66021$kI5.31976@nwrddc02.gnilink.net>
I think I have spent enough time browsing the FAQs and generally searching
the internet. What's the secret to installing as described in the subject.
I am using Dmake as descibed in README.win32 but cannot find the Template
for a GCC installation. I have resolved a few errors but cannot get past
the following:
gcc -mdll -o
..\perl58.dll -Wl,--base-file -Wl,perl.base -g -L"d:\programming\p
erl\5.8.0\lib\MSWin32-x86-multi-thread\CORE" -L"d:\programming\MinGW\lib" \
C:\Temp\mk00022a
where "d:\programming" is my root directory.
Flaming is welcome as long as accompanied by an answer.
------------------------------
Date: Thu, 24 Jul 2003 15:14:36 +1000
From: "Sisyphus" <kalinabears@iinet.net.au>
Subject: Re: Install Perl Bin on Win32 Using Mingw (GCC)
Message-Id: <3f1f6c4b$0$23589$5a62ac22@freenews.iinet.net.au>
"Matthew Ogan" <mattogan@verizon.net> wrote in message
news:8YITa.66021$kI5.31976@nwrddc02.gnilink.net...
> I think I have spent enough time browsing the FAQs and generally searching
> the internet. What's the secret to installing as described in the
subject.
> I am using Dmake as descibed in README.win32 but cannot find the Template
> for a GCC installation. I have resolved a few errors but cannot get past
> the following:
>
> gcc -mdll -o
> ..\perl58.dll -Wl,--base-file -Wl,perl.base -g -L"d:\programming\p
> erl\5.8.0\lib\MSWin32-x86-multi-thread\CORE" -L"d:\programming\MinGW\lib"
\
> C:\Temp\mk00022a
>
> where "d:\programming" is my root directory.
>
Presumably that's part of what you get when you run dmake.
What was the error that was generated ?
Not sure of what you mean by a "Template for a GCC installation."
Here's a copy of some notes I kept from when I built 5.6.1 with gcc. Don't
treat them as Gospel, but there might be something there that helps. I used
gcc-2.95.2, but I gather later versions are quite suitable.
------------------------------------------------
Downloaded gcc-2.95.2 and dmake from the links provided in the perl source
'README.win32'.
I downloaded the entire gcc-2.95.2 folder, but you only need these items
from it:
README
fixes/README.quote-fix
INSTALL
mingw32-docs-html.exe (optional)
gcc-2.95.2-msvcrt.exe
fixes/quote-fix-msvcrt.exe
runtime-source-19991107.zip (I assume this is needed ... perhaps not)
Ran gcc-2.95.2-msvcrt.exe, then ran quote-fix-msvcrt.exe.
My perl source was build 626 source from activeState.
Amended makefile.mk as per instructions contained within.
Also changed line ~ 422 from:
OPTIMIZE = -g -O2
LINK_DBG =
to:
OPTIMIZE = -O2
LINK_DBG =
Otherwise you get a very big perl.exe and perl56.dll.
For further size reduction maybe change the second line to:
LINK_DBG = -s
(I didn't bother with that)
Had to amend 'stdio.h' as mentioned in perl source 'README.win32'.
Added my \dmake\bin and my \gcc\bin to the path.
Ran 'dmake', 'dmake test' and 'dmake install'.
Add my \perl\bin to the path and we're away !!
-----------------------------------------------
> Flaming is welcome as long as accompanied by an answer.
>
Haven't supplied an answer ..... so I'm not allowed to flame .... damn! :-)
(I wouldn't do that, anyway.)
Cheers,
Rob
------------------------------
Date: Thu, 24 Jul 2003 06:51:24 GMT
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Larry W... out of work ?? Impossible... or...
Message-Id: <af2a5cfa05a333b2408056c6444a19cf@free.teranews.com>
>>>>> "stu7" == stu7 <stuseven@hotmail.com> writes:
stu7> *** I was a little surprised to see anyone named
stu7> *** randal schwartz jump on this teetering bandwagon
stu7> *** of jeering spammers... isnt he supposed to be one of
stu7> *** the good guys ?
Yes, I am. And I am. :)
You come in here, with very little respect for that which has gone on
before you. I'm not asking you to accept hand-in-glove all the things
we say here. But if you pay attention, you'll get the respect you
might need, including getting your questions answered.
Your post of a few days ago contained some bad facts, and some
mis-conclusions based on those facts. You may think you're clever for
producing such a document. I think you're deluded, either because you
don't know, or because you want to deliberately mislead, or maybe
you've just been misinformed.
And then, in response to correction, both recently, and over the past
times I've seen you post, you appear still to be more interested in
having it precisely your way instead of realizing that you're coming
in to a culture here that has been established based on collective
reasoning and rationale about what works and what doesn't. Being
online has a culture. Usenet has a culture. CLPM has a culture. You
seem to be ignoring all of those.
Hence, you are likely to be rejected, and even attacked, because you
can't seem to respect the existing culture. Maybe you do that in real
life too -- in which case, I feel sorry for you. Maybe you only do
that online, or even just here, in which case the only outcome is that
you'll never get what you want here, unless it's to be interacted with
as a troll.
So, you have three choices. Go away, be a troll, or accept the
culture. I don't care which you do. Each choice has consequences,
however.
I've been a member of the Perl culture since nearly the beginning.
I've been online since the BBS days, and on the Internet since before
it was called the Internet, and on Usenet within a year of its
creation. I have a pretty good sense of what works here, and what
doesn't. You are part of what doesn't work, at the moment. You
can change that, or continue to be an a**hole. It's up to you.
print "Just another Perl hacker,"
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
------------------------------
Date: Thu, 24 Jul 2003 11:08:48 +0800
From: Dan Jacobson <jidanni@jidanni.org>
Subject: simple web site mapper
Message-Id: <874r1c8vun.fsf@jidanni.org>
Say, does this working simple web site mapper (vs. Eric Raymond's
extra large version) have any stuffing hanging out that perl novice me
ought to fix? Say, how does one do '/bin/sh -e' in perl? Would
rewriting it in python be as easy? Does perl have an internal "ls"
that could be called as easy? File::Find couldn't give me the ls -R
order I prefer I suppose. Goal: to use even less lines of code.
use strict;
require HTML::HeadParser;
my $dir=<~/mywebsite>; #where files are on my computer
my $name="Bob Blobkowski";
my $url='http://blobkowski.org/';
chdir $dir||die;
print <<EOF;
<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"><HTML><TITLE>$name\'s site map</TITLE>
</HEAD><BODY><H1>$name\'s site map</H1>\n<P><A href="$url">$url</A> as of
EOF
system "date"; print '</P><HR><PRE>';
my $p = HTML::HeadParser->new; my $d;
open LS, "ls -R|"||die;
while(<LS>){ #order nicer than find(1)
chomp;
if(s@:$@@){$d=$_;next}
if(/\.(txt|html)$/){s@^@$d/@;s/..//;print "<A href=\"$_\">$_</A>\n";
if(/\.html$/){$p->parse_file($_);print "\t",$p->header('Title'),"\n";}}}
print "</PRE></BODY></HTML>";
------------------------------
Date: 24 Jul 2003 04:30:16 GMT
From: Martien Verbruggen <mgjv@tradingpost.com.au>
Subject: Re: size of graphics files....
Message-Id: <slrnbhuo6q.1le.mgjv@verbruggen.comdyn.com.au>
On Wed, 23 Jul 2003 09:39:04 +0200,
Bill Parker <bill@gites.org.uk> wrote:
> Is it possible to easily mimic php's getimagesize function in perl? In
> particular, I want to get at an images size in KB and X and Y values.
>
> I fully admit to laziness in having purchased but not yet read Verbruggen's
> "Graphics Programming with Perl" but I'm hoping this is such a simple task
> that a) I won't need Image::Magick or whatever and b) someone else already
> has a code fragment to hand
The book advises one to use Image::Size for this, and I fully
subscribe to that view :)
It also has some code that shows how to get this information for file
formats that Image::Size doesn't support.
Martien
--
|
Martien Verbruggen | We are born naked, wet and hungry. Then
Trading Post Australia | things get worse.
|
------------------------------
Date: Thu, 24 Jul 2003 04:31:49 GMT
From: Joseph Ellis <jandellis@hotmail.com>
Subject: Re: Style question regarding subroutines and lexical variables
Message-Id: <emnuhv0dpj3iqnkn4rjlfslbeeueatrqtg@4ax.com>
On 24 Jul 2003 03:33:32 GMT, "A. Sinan Unur" <asu1@c-o-r-n-e-l-l.edu>
wrote:
>Joseph Ellis <jandellis@hotmail.com> wrote in
>news:3giuhv8v1atb61lrdorsaf41cu6pkl3q33@4ax.com:
>
>> Hello all...I am fairly new to Perl and am hoping to glean some advice
>> from those of you who have been around the Perl block a few times.
>
>Disclaimer: I haven't been around the block even once yet.
>
>If you haven't done so already, I will recommend taking a look at:
>
>perldoc perlsub
>
>> I am currently writing a program that consists of a handful of
>> subroutines, with one subroutine calling another subroutine, etc, all
>> to generate a particular hash.
>>
>> So far I'm giving most of my variables file scope, but I don't think
>> that's really the best thing to do, stylistically and otherwise.
>>
>> Consider the following (syntax notwithstanding)...
>>
>> my $l, $m, $n, $o, $p;
>> my %hash;
>>
>> sub one {
>> use / modify all those global variables;
>> &two();
>> return %hash;
>> }
>
>perlsub has this to say:
>
> Not only does the "&" form make the argument list optional, it also
> disables any prototype checking on arguments you do provide. This is
> partly for historical reasons, and partly for having a convenient way
> to cheat if you know what you're doing. See Prototypes below.
>
>You really do not need to use &two(), two() will do just fine.
I have read that, but so far I am sticking with using the &, because I
don't think I sufficiently know what I'm doing yet to "cheat".
>
>>
>> sub two {
>> use / modify a couple of the scalars and the hash;
>> &three();
>> }
>>
>> sub three {
>> use / modify a couple of the other scalars and the hash
>> }
>>
>> Would it be advisable / more efficient / more aesthetically pleasing /
>> just plain better to create lexical variables within each subroutine,
>> passing copies of them around as arguments, or is the above
>> pseudo-script fine the way it is?
>
>You can pass around references to the hashes. That way, you do not need
>to make changes to the code in the subroutines if you change the names of
>the hashes or other variables you are modifying, and you avoid creating
>copies of large data structures.
Ahh, that sounds like what I'm looking for. I haven't learned
anything about references yet. The only book I have is the Llama,
which suggests perlref and perlreftut. I'll study more there.
>
>> What if there were 15 variables and 20 subroutines? Or 30 variables
>> and 5 subroutines?
>
>Regardless of language, if I see a method/function/subroutine being
>called with 30 arguments, I am inclined to think there is a design issue.
>But I am really not sure what you mean by these.
I was just being hypothetical, which is significantly different than
hypothetically being...
Thanks for your help.
>
>Sinan
Joseph
------------------------------
Date: Sat, 19 Jul 2003 01:59:56 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re:
Message-Id: <3F18A600.3040306@rochester.rr.com>
Ron wrote:
> Tried this code get a server 500 error.
>
> Anyone know what's wrong with it?
>
> if $DayName eq "Select a Day" or $RouteName eq "Select A Route") {
(---^
> dienice("Please use the back button on your browser to fill out the Day
> & Route fields.");
> }
...
> Ron
...
--
Bob Walton
------------------------------
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 5265
***************************************
