[31517] in Perl-Users-Digest
Perl-Users Digest, Issue: 2776 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jan 18 21:09:48 2010
Date: Mon, 18 Jan 2010 18:09:13 -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 Mon, 18 Jan 2010 Volume: 11 Number: 2776
Today's topics:
Re: a defense of ad hoc software development <gusenet@comcast.net>
After a long day. <pshendley@gmail.com>
Re: FAQ 9.16 How do I decode a CGI form? <pshendley@gmail.com>
Re: perl runtime model <sreservoir@gmail.com>
Re: perl runtime model <OJZGSRPBZVCX@spammotel.com>
Re: perl runtime model <OJZGSRPBZVCX@spammotel.com>
Re: perl runtime model <pengyu.ut@gmail.com>
Re: perl runtime model <pengyu.ut@gmail.com>
Re: perl runtime model <sreservoir@gmail.com>
Re: perl runtime model <jurgenex@hotmail.com>
Re: search and replace in Perl <rvtol+usenet@xs4all.nl>
Re: search and replace in Perl <tadmc@seesig.invalid>
Variable set to 0 <fgnowfg@gmail.com>
Re: Variable set to 0 <kevinsproule@hotmail.com>
Re: Variable set to 0 <sreservoir@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 18 Jan 2010 19:18:40 -0500
From: Greg Menke <gusenet@comcast.net>
Subject: Re: a defense of ad hoc software development
Message-Id: <86iqaz6j6n.fsf@apshai.pienet>
ccc31807 <cartercc@gmail.com> writes:
> On Jan 16, 12:30 am, seeWebInst...@rem.intarweb.org (Robert Maas,
> http://tinyurl.com/uh3t) wrote:
>> I'm less familiar with military specifications, but I would guess
>> these are like InterNet specs, where you might code an API module
>> for each set of specs, coding directly from the specs, then write
>> the rest of the application in a more experimental style.
>
> http://homepage.mac.com/simon.j.wright/pushface.org/mil_498/index.htm
>
> Read it and weep.
Nice!
And whatever your write Shall Conform to several (possibly
contradictory) coding standards both locally defined and those visited
upon the world by ISO/CMMI (as mandated by management who doesn't
actually have to use them). And whatever you do end up coding has to be
documented according to appendices of the aforementioned standards
specs, and all changes to it also Shall Conform to the change control
specs. And when you put your (surviving) code through Validation &
Verification, the pencil pushers who apply that process have full
editorial control over your code- from accept to change to reject, and
are unencumbered by any knowledge, responsibility or accountability for
the project.
And while you contend with all that, you have the undocumented changes
(demands) levied upon you by others up the food chain which have to go
in amongst the formal stuff.
>> It is sometimes desireable to quickly write non-functional UI which
>> shows the user how it "looks", and get their approval of that,
>> before starting the real code under the UI.
>
> Absolutely. However, one hundred percent of my scripts are designed to
> be run from the command line, sometimes as cron jobs, sometimes called
> by DOS batch files (for users uncomfortable with the CLI). I've
> learned to write real specific prompts for the input data, and write
> sanity checks throughout (e.g., "You entered the date of August 71,
> 2009. Do you want to continue? [y|n]")
And sometimes the "look" of the operating code requires the real code.
Sometimes the "UI" is a packet exchange protocol, and with debugging
enabled, a series of messages sent to a debugging console.
Gregm
------------------------------
Date: Mon, 18 Jan 2010 15:26:11 -0800 (PST)
From: Permostat <pshendley@gmail.com>
Subject: After a long day.
Message-Id: <08573a57-0d50-4e58-98d2-633e616da99e@34g2000yqp.googlegroups.com>
This is my recipe for duck Foie Gras
Serves 5
INGREDIENTS:
10 slices (40/60g) of Rougi=E9 flash frozen duck foie gras
100g/3.5oz. Port wine
50g/1.75oz. honey
150g/5.25oz. balsamic vinegar
200g/7oz. veal stock
150g/5.25oz. onion confit
1 French baguette
PREPARATION:
Caramelize the honey, stir in balsamic vinegar, reduce. Add Port wine,
reduce. Add the veal stock, and reduce to obtain a syrupy sauce.
Season with salt and pepper and then sear or grill the seasoned and
thawed slices of foie gras. Keep warm on paper towels.
Brown slices of French bread in the same frying pan used to sear the
foie gras or on the grill. Put 15g of onion confit on each toast.
Place a slice of foie gras on each toast, set on a warm plate, and
baste with the sauce reduction. Serve immediately, alone, or with a
mixed green salad seasoned with balsamic vinegar.
Wonderful for anniversaries or dinner with longtime friends.
ferm--
------------------------------
Date: Mon, 18 Jan 2010 15:28:12 -0800 (PST)
From: Permostat <pshendley@gmail.com>
Subject: Re: FAQ 9.16 How do I decode a CGI form?
Message-Id: <0e8c4482-1269-4aef-ad5c-1c6246ebf35b@m16g2000yqc.googlegroups.com>
On Jan 16, 5:04=A0pm, Helmut Richter <hh...@web.de> wrote:
> On Fri, 15 Jan 2010, Mumia W. wrote:
> > I think you're trying to demonstrate a bug in CGI.pm, and you're doing =
that
> > quite well,
>
> Up to now, I was not able to say what exactly my problem is. This is in
> part due to the fact that the CGI.pm documentation fails to say what
> *exactly* CGI.pm does with UTF-8, so that I cannot check the behaviour
> against the documentation. Let me try again.
>
> The documentationhttp://perldoc.perl.org/CGI.htmlsays:
>
> | -utf8
> |
> |
> | This makes CGI.pm treat all parameters as UTF-8 strings. Use this with =
care,
> | as it will interfere with the processing of binary uploads. It is bette=
r to
> | manually select which fields are expected to return utf-8 strings and
> | convert them using code like this:
> |
> | =A0 =A01. use Encode;
> | =A0 =A02. my $arg =3D decode utf8=3D>param('foo');
>
> What does the first sentence mean: "This makes CGI.pm treat all parameter=
s
> as UTF-8 strings"? What is "treat as" in this context?
>
> The only way I find for giving it a meaningful interpretation is the
> following.
>
> a. The handling of UTF-8 characters is documented in
> =A0 =A0http://perldoc.perl.org/perlunitut.html. The main lesson to be lea=
rnt
> =A0 =A0is that the writer of any perl program is responsible to know whic=
h of
> =A0 =A0his strings are bytestrings or textstrings. If he does not know, h=
e
> =A0 =A0might try to output textstrings to a binary file (does not work fo=
r
> =A0 =A0"wide" characters), or output bytestrings to a UTF-8 encoded file
> =A0 =A0(renders "wide" characters as a sequence of two or more characters=
), or
> =A0 =A0compare a textstring with a bytestring (unpredictable whether equa=
l
> =A0 =A0strings will be recognised as equal).
>
> b. Hence, it is vital that the user of the CGI.pm module know whether the
> =A0 =A0result of param('param_name') is a bytestring or a textstring. If
> =A0 =A0bytestring, it has to be output with STDOUT as binary; if textstri=
ng,
> =A0 =A0as UTF-8 (that is, after binmode (STDOUT, ":utf8")). If bytestring=
, it
> =A0 =A0can be compared only with other bytestrings whose encoding is know=
n to
> =A0 =A0be the same; if textstring, it can only be compared with other
> =A0 =A0textstrings. If bytestring, a default setting of a field in the fo=
rm
> =A0 =A0must also be a bytestring; if textstring, it must be a textstring.=
If
> =A0 =A0one of the input string (the value of param() at the start) and th=
e
> =A0 =A0output string (the default setting of the field in the form) is a
> =A0 =A0textstring and the other is a bytestring, then the user input will=
not
> =A0 =A0properly be reused in a subsequent iteration of the form.
>
> c. The documentation does not say what kind of strings the param()
> =A0 =A0function yields or expects. It is plausible that they are bytestri=
ngs
> =A0 =A0in the absence of any specification, but what if the -utf8 pragma =
is
> =A0 =A0specified?
>
> d. The first possible interpretation is that the param() still yields
> =A0 =A0bytestrings even with that pragma. Then the user of CGI.pm has to =
take
> =A0 =A0care that all other strings with which the parameter is defaulted =
or
> =A0 =A0compared (as described as item (b) above) are bytestrings as well.=
But
> =A0 =A0then the pragma simply has no effect at all.
>
> e. The second possible interpretation is that, with the -utf8 pragma,
> =A0 =A0param() delivers the form input data as textstrings. Then they can=
also
> =A0 =A0be defaulted to textstrings, compared with other textstrings, and
> =A0 =A0output to a new form provided that STDOUT is in :utf8 mode. This w=
ould
> =A0 =A0not only be a reasonable behaviour but an extremely useful one.
> =A0 =A0Therefore I find this the most plausible interpretation.
>
> f. Up to now, we have not considered uploading binary files. If behaviour
> =A0 =A0(e) is intended, which we do not know due to lack of unambiguous
> =A0 =A0documentation, then one could think of setting :utf8 mode also on
> =A0 =A0STDIN. However, this would be a very bad idea, as then the entire =
input
> =A0 =A0would have to be UTF-8 which is not the case for embedded binary f=
iles.
> =A0 =A0An alternative implementation would be to first extract uploaded f=
iles
> =A0 =A0from the input data, and then interpret the remainder as UTF-8 dat=
a
> =A0 =A0(which can be guaranteed if properly specified in the accept-chars=
et
> =A0 =A0option of the <form> tag). Again: This would not only be a reasona=
ble
> =A0 =A0behaviour but an extremely useful one. Therefore I find this the m=
ost
> =A0 =A0plausible interpretation.
>
> That a call to decode() for decoding input data is mentioned in the
> documentation as an *alternative* to the -utf8 pragma is another hint tha=
t
> behavious (e) is intended, and that the documenation warns against
> simultanous usage of -utf8 and binary upload is a hint in the same
> direction, suggesting that the implementation is used which I called "a
> very bad idea" under item (f).
>
> Now what actually happens is:
>
> 1. The strings yielded by param() are unusable as textstrings. They are
> =A0 =A0UTF-8 bytestrings, exactly as if the -utf8 pragma would not have b=
een
> =A0 =A0specified.
>
> 2. I was not able to produce any problems in the uploaded binary files
> =A0 =A0with or without the -utf8 pragma. The warning is futile.
>
> The module thus works quite differently from what I expect from the
> documentation. To sum up, the documentation says, it does something usefu=
l
> with UTF-8 data but may garble binary data. In fact, it does nothing at
> all with UTF-8 data, and because it does nothing, it does not do any harm=
.
>
> The documentation is not clear enough to tell whether it is a deficiency
> in the documentation or the program. The documentation should specify
> exactly what to expect, and the actual behavious is far from optimal (so
> fixing only the documentation is not the right solution).
>
> > First, you can't post to an HTML file:
> >http://www.lrz-muenchen.de/cgi/richter/test-utf.html. I changed that whe=
n I
> > ran your program.
>
> It's just the name of the file; it is the perl script I included. The
> Apache where I ran it accepted the file as CGI script despite its name
> (based on the directory where it is).
>
> > Second, mutipart/form-data is supposed to be for binary files, and as s=
uch is
> > not suitable for utf8 data /unless/ you wish to handle the convertion t=
o/from
> > utf8 yourself. I don't think that CGI.pm is misbehaving too badly.
>
> Yes, this is how the documentation says, but that is not true, as
> explained above in detail. And it *should* not be true: the CGI.pm module
> has access to the entire input string *before* any code conversions are
> done -- *this* is the right place for decoding the data, not in the perl
> script on a parameter by parameter basis.
>
> Thank you for looking into it.
>
> --
> Helmut Richter
Jeez....marry somebody.
ferm--
------------------------------
Date: Mon, 18 Jan 2010 18:35:42 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: perl runtime model
Message-Id: <hj2r8t$8gs$1@speranza.aioe.org>
On 1/18/2010 5:59 PM, Jürgen Exner wrote:
> Peng Yu<pengyu.ut@gmail.com> wrote:
>> On Jan 18, 9:55 am, smallpond<smallp...@juno.com> wrote:
>>> On Jan 18, 10:01 am, Peng Yu<pengyu...@gmail.com> wrote:
>>>
>>>> Could somebody let me know a reference on the runtime of a perl
>>>> script? I.e how a perl script run? What parts make a perl script be
>>>> slower than an equivalent, say, C programe?
>>>
>>> What do you mean by equivalent?
>>
>> Two programs are "equivalent" if and only if given the same input, the
>> output is the same. That is, what are used in the two programs do not
>> matter.
>>
>> Now, given the same input and the same output, theoretically, we can
>> have a fastest perl program and a fastest C program that are
>> equivalent. "fastest" is measured in terms of the runtime.
>>
>> It is generally understand that this fastest perl program is slower
>> than this fastest C program in a lot of cases. I want to understand
>> why it is so and what features in perl cause perl be slow in these
>> cases.
>
> C is a low-level language, much closer to native assembler code.
> Perl is a high-level language providing much more powerful features to
> the programmer. Of course those features come at a price.
>
>>> Perl scalar variables have runtime type checking and conversion. A
>>> "string" in C is just a pointer to memory with no checking, so of
>>> course the code runs much faster.
>>
>> Are you sure it is only the runtime type check make perl slower.
>
> No. The main difference is obviously that Perl is interpreted while C is
> compiled.
not quite. simplest scheme can be faster than simplest c simply because
the scheme interpreter is optimizing its lists and uses tail-calls for
recursion. but then, perl tries to be general-purpose, where scheme is
made for a specific mindset.
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
Date: Tue, 19 Jan 2010 01:00:51 +0100
From: "Jochen Lehmeier" <OJZGSRPBZVCX@spammotel.com>
Subject: Re: perl runtime model
Message-Id: <op.u6q6bpa8mk9oye@frodo>
On Mon, 18 Jan 2010 21:50:07 +0100, Peng Yu <pengyu.ut@gmail.com> wrote:
> 'man perl' lists a lot of documents. Would you please be specific on
> which one I should read?
Did you read my post? The question you are probably asking (the one you
elaborated on later in this thread) is not answered by those documents
directly; I mentioned "man perl" at that point because it was not clear
what you meant. You have to read the source code to find out what perl
does exactly when executing a script (some things are obvious, like
garbage collection, and interpretation instead of compilation, but I
assume you know all that already, don't you?).
> Would you please point me a webpage?
Did you actually look into any of the pages the search I mentioned turned
up? Several mention reasons why compiled languages are faster than
interpreted ones. Since you mentioned some logical language, I assume that
you are aware of the distinction between interpreted and compiled
languages. Is it not obvious then what makes any interpreted language
slower than a compiled one?
------------------------------
Date: Tue, 19 Jan 2010 01:12:43 +0100
From: "Jochen Lehmeier" <OJZGSRPBZVCX@spammotel.com>
Subject: Re: perl runtime model
Message-Id: <op.u6q6vhgnmk9oye@frodo>
On Tue, 19 Jan 2010 00:35:42 +0100, sreservoir <sreservoir@gmail.com>
wrote:
>>> Now, given the same input and the same output, theoretically, we can
>>> have a fastest perl program and a fastest C program that are
>>> equivalent. "fastest" is measured in terms of the runtime.
> not quite. simplest scheme can be faster than simplest c simply because
> the scheme interpreter is optimizing its lists and uses tail-calls for
> recursion.
He's not asking about simplest, but about fastest. Since C is allowing to
program closer to machine code than almost any other language known to
man, I'd rather say it would be very hard to beat a dedicated C
programmer. (And heck, he could just program a scheme interpreter in C
which is even more optimized to the specific problem than the normal
optimizing scheme interpreter - problem solved).
But on the other hand, I believe the OP is just conducting a social
experiment in this group (unless he is trying to solve homework), so I'll
sit back and enjoy the show. ;-)
/em opens a big can of popcorn
------------------------------
Date: Mon, 18 Jan 2010 16:25:26 -0800 (PST)
From: Peng Yu <pengyu.ut@gmail.com>
Subject: Re: perl runtime model
Message-Id: <8daf1c67-755c-4d5d-9375-7fbe9ef77bda@p8g2000yqb.googlegroups.com>
On Jan 18, 6:00=A0pm, "Jochen Lehmeier" <OJZGSRPBZ...@spammotel.com>
wrote:
> On Mon, 18 Jan 2010 21:50:07 +0100, Peng Yu <pengyu...@gmail.com> wrote:
> > 'man perl' lists a lot of documents. Would you please be specific on
> > which one I should read?
>
> Did you read my post? The question you are probably asking (the one you =
=A0
> elaborated on later in this thread) is not answered by those documents =
=A0
> directly; I mentioned "man perl" at that point because it was not clear =
=A0
> what you meant. You have to read the source code to find out what perl =
=A0
> does exactly when executing a script (some things are obvious, like =A0
> garbage collection, and interpretation instead of compilation, but I =A0
> assume you know all that already, don't you?).
>
> > Would you please point me a webpage?
>
> Did you actually look into any of the pages the search I mentioned turned=
=A0
> up? Several mention reasons why compiled languages are faster than =A0
> interpreted ones. Since you mentioned some logical language, I assume tha=
t =A0
> you are aware of the distinction between interpreted and compiled =A0
> languages. Is it not obvious then what makes any interpreted language =A0
> slower than a compiled one?
I don't think that you understand what I meant. Those pages don't give
as much details. It is not obvious what makes any interpreted language
slower than a compiled one. I want to know exactly what make an
interpreted language slower. And if perl is slow because it is
interpreted, can a perl script be compiled to a machine executable
code so that it will be as fast as a C program?
------------------------------
Date: Mon, 18 Jan 2010 16:26:35 -0800 (PST)
From: Peng Yu <pengyu.ut@gmail.com>
Subject: Re: perl runtime model
Message-Id: <51226f61-2359-4d64-9c65-1e1bd2da37c2@e27g2000yqd.googlegroups.com>
On Jan 18, 6:12=A0pm, "Jochen Lehmeier" <OJZGSRPBZ...@spammotel.com>
wrote:
> On Tue, 19 Jan 2010 00:35:42 +0100, sreservoir <sreserv...@gmail.com> =A0
> wrote:
>
> >>> Now, given the same input and the same output, theoretically, we can
> >>> have a fastest perl program and a fastest C program that are
> >>> equivalent. "fastest" is measured in terms of the runtime.
> > not quite. simplest scheme can be faster than simplest c simply because
> > the scheme interpreter is optimizing its lists and uses tail-calls for
> > recursion.
>
> He's not asking about simplest, but about fastest. Since C is allowing to=
=A0
> program closer to machine code than almost any other language known to =
=A0
> man, I'd rather say it would be very hard to beat a dedicated C =A0
> programmer. (And heck, he could just program a scheme interpreter in C =
=A0
> which is even more optimized to the specific problem than the normal =A0
> optimizing scheme interpreter - problem solved).
>
> But on the other hand, I believe the OP is just conducting a social =A0
> experiment in this group (unless he is trying to solve homework), so I'll=
=A0
> sit back and enjoy the show. ;-)
Your interpretation is wrong.
------------------------------
Date: Mon, 18 Jan 2010 20:42:02 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: perl runtime model
Message-Id: <hj32lq$o7k$2@speranza.aioe.org>
On 1/18/2010 7:25 PM, Peng Yu wrote:
> On Jan 18, 6:00 pm, "Jochen Lehmeier"<OJZGSRPBZ...@spammotel.com>
> wrote:
>> On Mon, 18 Jan 2010 21:50:07 +0100, Peng Yu<pengyu...@gmail.com> wrote:
>>> 'man perl' lists a lot of documents. Would you please be specific on
>>> which one I should read?
>>
>> Did you read my post? The question you are probably asking (the one you
>> elaborated on later in this thread) is not answered by those documents
>> directly; I mentioned "man perl" at that point because it was not clear
>> what you meant. You have to read the source code to find out what perl
>> does exactly when executing a script (some things are obvious, like
>> garbage collection, and interpretation instead of compilation, but I
>> assume you know all that already, don't you?).
>>
>>> Would you please point me a webpage?
>>
>> Did you actually look into any of the pages the search I mentioned turned
>> up? Several mention reasons why compiled languages are faster than
>> interpreted ones. Since you mentioned some logical language, I assume that
>> you are aware of the distinction between interpreted and compiled
>> languages. Is it not obvious then what makes any interpreted language
>> slower than a compiled one?
>
> I don't think that you understand what I meant. Those pages don't give
> as much details. It is not obvious what makes any interpreted language
> slower than a compiled one. I want to know exactly what make an
> interpreted language slower. And if perl is slow because it is
> interpreted, can a perl script be compiled to a machine executable
> code so that it will be as fast as a C program?
http://lmgtfy.org/?q=why+interpreted+program+slower+than+compiled
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
Date: Mon, 18 Jan 2010 17:47:26 -0800
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: perl runtime model
Message-Id: <7i3al5dj4jaosv5j5nsqt84pvf1a2orqtl@4ax.com>
sreservoir <sreservoir@gmail.com> wrote:
>On 1/18/2010 5:59 PM, Jürgen Exner wrote:
>> No. The main difference is obviously that Perl is interpreted while C is
>> compiled.
>
>not quite. simplest scheme can be faster than simplest c simply because
>the scheme interpreter is optimizing its lists and uses tail-calls for
>recursion.
I don't buy that argument. You may be right with the program conversion,
you can do just the same in C, too, you just have to do it manually.
On the other hand launching an interpreter, parsing the source code,
creating some form of executable code and starting that code adds
overhead that you simply don't have with code that is already compiled,
linked, and assembled.
jue
------------------------------
Date: Tue, 19 Jan 2010 01:07:22 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: search and replace in Perl
Message-Id: <4b54f7ba$0$22939$e4fe514c@news.xs4all.nl>
Tad McClellan wrote:
> Mumia W. <paduille.4061.mumia.w+nospam@earthlink.net> wrote:
>> my $regex = join('|',keys %regmap); # use alternation in regexp.>
>
> I once lost about 3 hours because I did it that way, so let me help
> others avoid such a fate...
>
> If you have a pattern that is a prefix of some other pattern, say "cow"
> and "cows", then you better do something to ensure that the longer
> one is leftmost in your regex's alternation.
>
> I usually just do a sort in descending order:
>
> my $regex = join('|', sort {$b cmp $a} keys %regmap);
Probably should have a "map +('\b\Q$_\E\b')," inserted as well.
--
Ruud
------------------------------
Date: Mon, 18 Jan 2010 20:08:34 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: search and replace in Perl
Message-Id: <slrnhla4qn.k1l.tadmc@tadbox.sbcglobal.net>
Dr.Ruud <rvtol+usenet@xs4all.nl> wrote:
> Tad McClellan wrote:
>> Mumia W. <paduille.4061.mumia.w+nospam@earthlink.net> wrote:
>
>>> my $regex = join('|',keys %regmap); # use alternation in regexp.>
>>
>> I once lost about 3 hours because I did it that way, so let me help
>> others avoid such a fate...
>>
>> If you have a pattern that is a prefix of some other pattern, say "cow"
>> and "cows", then you better do something to ensure that the longer
>> one is leftmost in your regex's alternation.
>>
>> I usually just do a sort in descending order:
>>
>> my $regex = join('|', sort {$b cmp $a} keys %regmap);
>
> Probably should have a "map +('\b\Q$_\E\b')," inserted as well.
All the keys in Mumia's code matched \w+, so no need for \Q\E.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
------------------------------
Date: Mon, 18 Jan 2010 16:47:42 -0800 (PST)
From: Faith Greenwood <fgnowfg@gmail.com>
Subject: Variable set to 0
Message-Id: <07de4f8d-63bf-438d-a4fd-d41fcd4a5da0@r5g2000yqb.googlegroups.com>
I have the following:
use strict;
use warnings;
my $number=0;
print "This:$number\n";
print "That:$number\n" if $number;
__END__
Of the two lines that print the variable, why does it print the first
line but not the second?
If I change the $number to equal 1, then both lines print fine.
thank you
------------------------------
Date: Mon, 18 Jan 2010 18:09:52 -0700
From: "Kevin Sproule" <kevinsproule@hotmail.com>
Subject: Re: Variable set to 0
Message-Id: <FD75n.9642$Ft3.5239@newsfe04.iad>
Faith,
In Perl the number 0 is false and any number other than zero is true. The
line with "if $number" will only execute when $number is not equal to 0.
Kevin Sproule
"Faith Greenwood" <fgnowfg@gmail.com> wrote in message
news:07de4f8d-63bf-438d-a4fd-d41fcd4a5da0@r5g2000yqb.googlegroups.com...
>I have the following:
>
> use strict;
> use warnings;
>
> my $number=0;
> print "This:$number\n";
> print "That:$number\n" if $number;
>
> __END__
>
> Of the two lines that print the variable, why does it print the first
> line but not the second?
> If I change the $number to equal 1, then both lines print fine.
>
> thank you
------------------------------
Date: Mon, 18 Jan 2010 20:38:49 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: Variable set to 0
Message-Id: <hj32fo$o7k$1@speranza.aioe.org>
On 1/18/2010 7:47 PM, Faith Greenwood wrote:
> I have the following:
>
> use strict;
> use warnings;
>
> my $number=0;
> print "This:$number\n";
> print "That:$number\n" if $number;
>
> __END__
>
> Of the two lines that print the variable, why does it print the first
> line but not the second?
> If I change the $number to equal 1, then both lines print fine.
>
> thank you
because 0 is, traditionally, not true, even in perl where false is
canonically undef.
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 2776
***************************************
