Variable set to 0

[Faith Greenwood]

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

 

[Kevin Sproule]

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

 

[sreservoir]

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.

 

[Uri Guttman]

s> because 0 is, traditionally, not true, even in perl where false is
s> canonically undef.

undef, '', 0 and '0' are the boolean false values for perl. there is no
canonical one. you can use them how you wish but they will all be false
under perl's boolean tests (which includes if modifier).

for the OP, what did you think 'if' means? that it was defined? for that
use the defined function:

print "That:$number\n" if defined $number;

that will print.

uri

 

[Jürgen Exner]

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?

Maybe because you explicitely tell Perl to print the second line only if
$number is true?

If I change the $number to equal 1, then both lines print fine.

Big surprise, 1 is a true value, 0 is not.

jue

 

[Jürgen Exner]

because 0 is, traditionally, not true, even in perl where false is
canonically undef.

That is not correct. While the boolean values of undef is indeed false,
this is by no means canonical. There are several other scalar values,
the numerical 0 just being one of them. Please see 'perldoc perldata'
for details.

jue

 

[sreservoir]

because 0 is, traditionally, not true, even in perl where false is
canonically undef.

No. False in perl is canonically a dualvar that is the empty string in
string context and 0 in numeric context (so there are no warnings on
numeric conversion, unlike a plain "").

~% perl -E'say defined !1'
1
~% perl -wE'say 0 + !1'
0
~% perl -wE'say "[", ("" . !1), "]"'
[]
~% perl -wE'say 0 + ""'
Argument "" isn't numeric in addition (+) at -e line 1.
0
~%

True is canonically the string "1".

~% perl -wle'print !1'
Use of uninitialized value in print at -e line 1.

~%

I suspect this is a historical thing that I never remembered.

 

[sreservoir]

That is not correct. While the boolean values of undef is indeed false,
this is by no means canonical. There are several other scalar values,
the numerical 0 just being one of them. Please see 'perldoc perldata'
for details.

huh. historically, the comparisons returned undef for false. well, I
guess you learn something new every day.

 

[sreservoir]

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.

No. False in perl is canonically a dualvar that is the empty string in
string context and 0 in numeric context (so there are no warnings on
numeric conversion, unlike a plain "").

~% perl -E'say defined !1'
1
~% perl -wE'say 0 + !1'
0
~% perl -wE'say "[", ("" . !1), "]"'
[]
~% perl -wE'say 0 + ""'
Argument "" isn't numeric in addition (+) at -e line 1.
0
~%

True is canonically the string "1".

~% perl -wle'print !1'
Use of uninitialized value in print at -e line 1.

~%

I suspect this is a historical thing that I never remembered.

a newer perl returns the same results as your perl.

false as a string never struck me as useful though.

 

[Uri Guttman]

BM> No. False in perl is canonically a dualvar that is the empty string in
BM> string context and 0 in numeric context (so there are no warnings on
BM> numeric conversion, unlike a plain "").

i know that but the OP's issue was not knowing that 0 was false or not
getting that if checked for false and not defined.

uri

 

[sreservoir]

BM> No. False in perl is canonically a dualvar that is the empty string in
BM> string context and 0 in numeric context (so there are no warnings on
BM> numeric conversion, unlike a plain "").

i know that but the OP's issue was not knowing that 0 was false or not
getting that if checked for false and not defined.

the problem with this group is that even when someone agrees with you,
they will disagree with your example.

 

[sreservoir]

On 1/18/2010 9:05 PM, Ben Morrow wrote:

No. False in perl is canonically a dualvar that is the empty string in
string context and 0 in numeric context (so there are no warnings on
numeric conversion, unlike a plain "").

~% perl -E'say defined !1'
1
~% perl -wE'say 0 + !1'
0
~% perl -wE'say "[", ("" . !1), "]"'
[]
~% perl -wE'say 0 + ""'
Argument "" isn't numeric in addition (+) at -e line 1.
0
~%

True is canonically the string "1".

~% perl -wle'print !1'
Use of uninitialized value in print at -e line 1.

~%

I suspect this is a historical thing that I never remembered.

a newer perl returns the same results as your perl.

Which version of perl was your original test? I get !1 defined for all
versions>5.6.0 (the oldest perl I have lying around).

whatever version it is that ships with fedora core 1. I never did get
that one to connect to the internet.

probably perl 5.6.0 or a 5.004. yes, I probably should update it. sue me

 

[sreservoir]

I don't know what you mean by 'historically'. sv_no (the canonical false
value) has been as I describe since 5.000; 4.036 had str_no, which
appears to be simply the empty string (I guess Perl 4 didn't have
numeric conversion warnings?).

I am now slightly confused, too. Must have been confused and/or sleep-
deprived when I thought that. Though I'm not sure how !1 managed to
emit the warning then.

 

[sreservoir]

...


This group has no problems.

You must have us confused with some other group.

No, just confusing it with some other definition of problem.

 

[Uri Guttman]

BM> No. False in perl is canonically a dualvar that is the empty string in
BM> string context and 0 in numeric context (so there are no warnings on
BM> numeric conversion, unlike a plain "").
BM> I know you know that, which is why I wasn't saying it to you. I was
BM> saying it to sreservoir, who apparently didn't.

then you should have replied to his post and not mine.

uri

 

[Wanna-Be Sys Admin]

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

print "That:$number\n" if defined $number;

or

print "That:$number\n" if $number ne "";

 

[Peter J. Holzer]

~% perl -wle'print !1'
Use of uninitialized value in print at -e line 1.

I suspect that your shell (csh?) is fooling you. If !1 is interpreted as
a history expansion and command 1 was empty the command really reads:

~% perl -wle'print '

which will produce the warning you see.

hp

 

[sreservoir]

I suspect that your shell (csh?) is fooling you. If !1 is interpreted as
a history expansion and command 1 was empty the command really reads:

~% perl -wle'print '

which will produce the warning you see.

~% echo $SHELL
/bin/csh

gah!

 

[sreservoir]

~% echo $SHELL
/bin/csh

gah!

in sh:
~% perl -wle'print !1'

~%