[30482] in Perl-Users-Digest
Perl-Users Digest, Issue: 1725 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jul 16 18:14:19 2008
Date: Wed, 16 Jul 2008 15:14:11 -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 Wed, 16 Jul 2008 Volume: 11 Number: 1725
Today's topics:
Re: String comparison operator trouble <szrRE@szromanMO.comVE>
Re: String comparison operator trouble <uri@stemsystems.com>
Re: String comparison operator trouble <szrRE@szromanMO.comVE>
Re: Translate BASH source <usenet@larseighner.com>
Re: Translate BASH source <fawaka@gmail.com>
Re: Translate BASH source <smallpond@juno.com>
Re: Translate BASH source <usenet@larseighner.com>
Which domain registrar best for perl scripting? <soup_or_power@yahoo.com>
Re: Which domain registrar best for perl scripting? <smallpond@juno.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 16 Jul 2008 12:24:36 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: String comparison operator trouble
Message-Id: <g5lhtl04rr@news4.newsguy.com>
Jürgen Exner wrote:
> Dave B <daveb@addr.invalid> wrote:
>> J.D. Baldwin wrote:
>>
>>> next if ( undef $item )
>>
>> $item == undef
>
> This doesn't do what you seem to think it is doing.
Indeed, == forces a numeric context, so undef becomes 0. using 'eq'
interestingly seems to work (though, still with warnings - see below.)
> First of all it will trigger two warnings (for generic $item):
> - Use of uninitialized value in numeric eq (==) [*]
> - Argument "...." isn't numeric in numeric eq (==) [**]
>
>
> [*]: because undef is not initialized, surprise, surprise
> [**]: because in the generic case $item may contain a string or -gasp-
> be undefined instead of number.
I get a different set of warnings (using both 5.10.0 and 5.8.8)
$ perl5.8.8 -Mstrict -Mwarnings -we 'my $x = 1; print +($x == undef ?
"[undef]" : "[$x]"), "\n";'
Warning: Use of "undef" without parentheses is ambiguous at -e line 1.
Search pattern not terminated or ternary operator parsed as search
pattern at -e line 1.
I'm not sure where it's getting "Search pattern from, but I'm guessing
this has something to do with using (if ? then : else) instead of
if{}else{} ?
$ perl5.8.8 -Mstrict -Mwarnings -we 'my $x = 1; print +($x eq (undef)
? "[undef]" : "[$x]"), "\n";'
Use of uninitialized value in string eq at -e line 1.
[1]
$ perl5.8.8 -Mstrict -Mwarnings -we 'my $x = 0; print +($x eq (undef)
? "[undef]" : "[$x]"), "\n";'
Use of uninitialized value in string eq at -e line 1.
[0]
$ -Mstrict -Mwarnings -we 'my $x = undef; print +($x eq (undef) ?
"[undef]" : "[$x]"), "\n";'
Use of uninitialized value in string eq at -e line 1.
Use of uninitialized value in string eq at -e line 1.
[undef]
Of course, I wouldn't use this in any real code, and one should always
use defined($scalar) to test for defininty.
--
szr
------------------------------
Date: Wed, 16 Jul 2008 19:38:02 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: String comparison operator trouble
Message-Id: <x7k5flaack.fsf@mail.sysarch.com>
>>>>> "s" == szr <szrRE@szromanMO.comVE> writes:
s> Jürgen Exner wrote:
>> Dave B <daveb@addr.invalid> wrote:
>>> J.D. Baldwin wrote:
>>>
>>>> next if ( undef $item )
>>>
>>> $item == undef
>>
>> This doesn't do what you seem to think it is doing.
s> Indeed, == forces a numeric context, so undef becomes 0. using 'eq'
s> interestingly seems to work (though, still with warnings - see below.)
what do you mean seems to work? try '' eq undef. the rule is simple,
don't use undef in any comparisons. that is why defined is NEEDED. it is
the only way to test for undef (which is out of band data for all other
ops).
s> Of course, I wouldn't use this in any real code, and one should always
s> use defined($scalar) to test for defininty.
then don't say things like it seems to work for eq when you know it
doesn't.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Wed, 16 Jul 2008 13:46:24 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: String comparison operator trouble
Message-Id: <g5lmn00beg@news4.newsguy.com>
Uri Guttman wrote:
>>>>>> "s" == szr <szrRE@szromanMO.comVE> writes:
>
> > Jürgen Exner wrote:
> >> Dave B <daveb@addr.invalid> wrote:
> >>> J.D. Baldwin wrote:
> >>>
> >>>> next if ( undef $item )
> >>>
> >>> $item == undef
> >>
> >> This doesn't do what you seem to think it is doing.
>
> s> Indeed, == forces a numeric context, so undef becomes 0. using
> s> 'eq' interestingly seems to work (though, still with warnings -
> s> see below.)
>
> what do you mean seems to work? try '' eq undef. the rule is simple,
> don't use undef in any comparisons. that is why defined is NEEDED. it
> is the only way to test for undef (which is out of band data for all
> other ops).
>
> s> Of course, I wouldn't use this in any real code, and one should
> always s> use defined($scalar) to test for defininty.
>
> then don't say things like it seems to work for eq when you know it
> doesn't.
No need to get upset. "Seems to work" only referred to having to
appearance to work as expected within the limit of those test cases. I
never said it's something that should be used, and in fact, I pointed to
the exact opposite, to not use such a construct and instead use
defined($scalar)
--
szr
------------------------------
Date: Wed, 16 Jul 2008 18:09:38 +0000 (UTC)
From: Lars Eighner <usenet@larseighner.com>
Subject: Re: Translate BASH source
Message-Id: <slrng7se1d.1r1.usenet@debranded.larseighner.com>
In our last episode, <50bcc$487e2b7e$89e0e08f$2685@news1.tudelft.nl>, the
lovely and talented Leon Timmermans broadcast on comp.lang.perl.misc:
> On Wed, 16 Jul 2008 17:02:02 +0000, Lars Eighner wrote:
>> Will 'require' serve as a translation for Bash 'source' ('.').
>>
>> I am trying translate a BASH script.
>>
>> The Bash script includes something like
>>
>> . filefoo
>>
>> where filefoo is a whole bunch of variable assignments.
>>
>> It is easy enough to translate the variable assignments to perl.
>>
>> If I translate filefoo and stick a 'return 1;' at the bottom, would
>> 'require filefoo' be a reasonable translation of the Bash . filefoo?
> The literal translation of that would be do.
> do 'filefoo';
> Having said that, I'm not sure a literal translation from bash to Perl
> would make a good program. Is there any reason you need to translate it?
Well, yes. It doesn't work.
I want Nanoblogger to work for me on a FreeBSD system. I have overcome many
obstacles so far, but Nanoblogger occasionally emits empty documents,
apparently at random, and this is a silent gotcha. Clearing cache,
previously generated documents, and so forth, on each attempt results in
different pages that coming out empty. On various runs I get every document
out right sometimes, but rarely get them all out. I suspect BASH limits
might be the culprit, but they are all maxed out.
I suspect the author's point in Nanoblogger is all the wonderful things you
can do with Bash and stream tools (I've learned more sed in this process than
I ever wanted to know). And when it works, it works great.
I, however, am not interested in a Bash demo, but in a working blog. The
main features I like about Nanoblogger are:
*flat file database
*only requires a command line editor
*does not require a javascript-enabled browser
I want to use it to generate static pages. I won't have direct entry of
user comments with forms, etc. Security, in short, is no issue. But
avoiding OO perl modules is. I'm not interested in a bunch of scoping crap
and inscrutable notation. And the reason this particular question is here
is because when I consult the perl docs with simple issue like this,
I get a bunch of Module::OO::Crap instead of a simple explanation of how to
include some code from another file.
This is why I fear Perl 6: because so far as I can tell, it only promises
more of the same.
--
Lars Eighner <http://larseighner.com/> usenet@larseighner.com
"We have no opinion on your Arab - Arab conflicts, such as your dispute with
Kuwait." -- Bush's Ambassador April Glaspie, giving Saddam Hussein
the greenlight to invade Kuwait.
------------------------------
Date: Wed, 16 Jul 2008 21:20:51 +0200
From: Leon Timmermans <fawaka@gmail.com>
Subject: Re: Translate BASH source
Message-Id: <dd9cc$487e4a13$89e0e08f$2685@news1.tudelft.nl>
On Wed, 16 Jul 2008 18:09:38 +0000, Lars Eighner wrote:
>
> I want Nanoblogger to work for me on a FreeBSD system. I have overcome
> many obstacles so far, but Nanoblogger occasionally emits empty
> documents, apparently at random, and this is a silent gotcha. Clearing
> cache, previously generated documents, and so forth, on each attempt
> results in different pages that coming out empty. On various runs I get
> every document out right sometimes, but rarely get them all out. I
> suspect BASH limits might be the culprit, but they are all maxed out.
>
Debugging a 2700 line shell script is not an easy task to say the least.
> I suspect the author's point in Nanoblogger is all the wonderful things
> you can do with Bash and stream tools (I've learned more sed in this
> process than I ever wanted to know).
>
Yeah, probably so.
> I, however, am not interested in a Bash demo, but in a working blog.
> The main features I like about Nanoblogger are:
> *flat file database
> *only requires a command line editor
> *does not require a javascript-enabled browser
>
I'm sure there are more blogs that do that. If not, building one from
scratch might be easier that translating this one. Also, it will probably
take you a lot less than 2700 LOCs.
> I want to use it to generate static pages. I won't have direct entry of
> user comments with forms, etc. Security, in short, is no issue. But
> avoiding OO perl modules is. I'm not interested in a bunch of scoping
> crap and inscrutable notation. And the reason this particular question
> is here is because when I consult the perl docs with simple issue like
> this, I get a bunch of Module::OO::Crap instead of a simple explanation
> of how to include some code from another file.
>
I agree OO is sometimes overused, but I can't say that that happens a lot
in the Perl community. In fact for a long time it was underused. Despite
its shortcomings, you sound like you're throwing out the baby with the
bath water.
> This is why I fear Perl 6: because so far as I can tell, it only
> promises more of the same.
Perl has always been a multi-paradigm language, and Perl 6 isn't going to
change that. If you want to code OO code, it will enable you to do so. If
you want to write non-OO code, it enable that too.
Leon Timmermans
------------------------------
Date: Wed, 16 Jul 2008 15:53:49 -0400
From: smallpond <smallpond@juno.com>
Subject: Re: Translate BASH source
Message-Id: <c999e$487e51dd$25890@news.teranews.com>
Lars Eighner wrote:
>
> ... And the reason this particular question is here
> is because when I consult the perl docs with simple issue like this,
> I get a bunch of Module::OO::Crap instead of a simple explanation of how to
> include some code from another file.
>
> This is why I fear Perl 6: because so far as I can tell, it only promises
> more of the same.
>
perl documentation is complete, but not heavily cross-linked. When you
find a term that is close to the information that you need, there is no
guarantee that wading through 20 pages of documentation will send you to
what you need to know. This problem has happened to everyone.
It would help if there was more higher-level concept documentation for
perl, but the language is such a mixed bag that it would end up being
more exceptions than rules.
In this case, however, the first paragraph of the perlmod documentation
which provided the stream of Module::OO::Crap (which I'm expecting to see
on CPAN any day now) mentions three ways of including a file:
"do", "require." or "use"
Looking up the individual documentation on those:
perldoc -f do
would have told you that it was "do" that you were looking for. So I
think the secret is to read just the introduction carefully, and avoid
the full document unless or until you are sure its the one you need.
--S
** Posted from http://www.teranews.com **
------------------------------
Date: Wed, 16 Jul 2008 20:39:41 +0000 (UTC)
From: Lars Eighner <usenet@larseighner.com>
Subject: Re: Translate BASH source
Message-Id: <slrng7smqo.2jp.usenet@debranded.larseighner.com>
In our last episode, <dd9cc$487e4a13$89e0e08f$2685@news1.tudelft.nl>, the
lovely and talented Leon Timmermans broadcast on comp.lang.perl.misc:
> On Wed, 16 Jul 2008 18:09:38 +0000, Lars Eighner wrote:
>> I, however, am not interested in a Bash demo, but in a working blog.
>> The main features I like about Nanoblogger are:
>> *flat file database
>> *only requires a command line editor
>> *does not require a javascript-enabled browser
>>
> I'm sure there are more blogs that do that. If not, building one from
> scratch might be easier that translating this one. Also, it will probably
> take you a lot less than 2700 LOCs.
You are probably right --- and no doubt eliminating all of the stuff I know
I will never want would make it much shorter, even if I can't make it
better. Let's say this is a warm-up exercise.
--
Lars Eighner <http://larseighner.com/> usenet@larseighner.com
War on Terrorism: Bad News from the Sanity Front
"In this autumn of anger, even a liberal can find his thoughts turning to ...
torture." --Jonathan Alter,_Newsweek_
------------------------------
Date: Wed, 16 Jul 2008 11:56:59 -0700 (PDT)
From: "souporpower@gmail.com" <soup_or_power@yahoo.com>
Subject: Which domain registrar best for perl scripting?
Message-Id: <ccb7b751-3d2b-474d-a595-f74958a6b2c0@d1g2000hsg.googlegroups.com>
Hi
I have written some perl scripts using the following packages:
URI::URL;
LWP::UserAgent;
HTTP::Request;
HTTP::Request::Common;
HTTP::Request::Form;
HTTP::Cookies;
HTML::TreeBuilder 3.0;
WWW::Mechanize;
I want to put my perl scripts on a hosted domain. When one of the
domain registrars Godaddy was contacted, they techies told me they
won't support Mechanize among other things.
So I tried another registrar namecheap.com who did support the modules
I need, however, won't let me run my scripts because of their high CPU
usage. Currently my domain with namecheap.com is suspended.
I don't want to make the same mistakes again. Can anyone tell me which
registrar is best for high performance perl scripts? Is Yahoo good?
They list the perl modules at their site, but I didn't see Mechanize.
Thanks for your help
------------------------------
Date: Wed, 16 Jul 2008 16:05:24 -0400
From: smallpond <smallpond@juno.com>
Subject: Re: Which domain registrar best for perl scripting?
Message-Id: <c8d7a$487e5494$29459@news.teranews.com>
souporpower@gmail.com wrote:
> Hi
>
> I have written some perl scripts using the following packages:
>
>
> URI::URL;
> LWP::UserAgent;
> HTTP::Request;
> HTTP::Request::Common;
> HTTP::Request::Form;
> HTTP::Cookies;
> HTML::TreeBuilder 3.0;
> WWW::Mechanize;
>
> I want to put my perl scripts on a hosted domain. When one of the
> domain registrars Godaddy was contacted, they techies told me they
> won't support Mechanize among other things.
> So I tried another registrar namecheap.com who did support the modules
> I need, however, won't let me run my scripts because of their high CPU
> usage. Currently my domain with namecheap.com is suspended.
>
> I don't want to make the same mistakes again. Can anyone tell me which
> registrar is best for high performance perl scripts? Is Yahoo good?
> They list the perl modules at their site, but I didn't see Mechanize.
>
> Thanks for your help
You first need to understand the difference between a domain registrar and
a web host - they are two different things. Web hosting companies will
tell you the level of service they provide at what cost. "Free" websites
provided by domain registrars are worth the price you pay for them.
--S
** Posted from http://www.teranews.com **
------------------------------
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 1725
***************************************
