[32330] in Perl-Users-Digest
Perl-Users Digest, Issue: 3597 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jan 21 16:09:28 2012
Date: Sat, 21 Jan 2012 13:09:10 -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 Sat, 21 Jan 2012 Volume: 11 Number: 3597
Today's topics:
Collecting specific values from hash reference <smilesonisamal@gmail.com>
Re: perl syntax check <willem@toad.stack.nl>
Perl versions in the wild (was: When is @_ undefined?) <hjp-usenet2@hjp.at>
Re: ssh tunnel <hjp-usenet2@hjp.at>
Re: ssh tunnel <ben@morrow.me.uk>
Re: ssh tunnel <hjp-usenet2@hjp.at>
Re: ssh tunnel <ben@morrow.me.uk>
Re: When is @_ undefined? <kaz@kylheku.com>
Re: When is @_ undefined? <rweikusat@mssgmbh.com>
Re: When is @_ undefined? <willem@toad.stack.nl>
Re: When is @_ undefined? (Tim McDaniel)
Re: When is @_ undefined? <kaz@kylheku.com>
Re: When is @_ undefined? <willem@toad.stack.nl>
Re: When is @_ undefined? <hjp-usenet2@hjp.at>
Re: When is @_ undefined? <hjp-usenet2@hjp.at>
Re: When is @_ undefined? (Randal L. Schwartz)
Re: When is @_ undefined? <hjp-usenet2@hjp.at>
Re: When is @_ undefined? <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 21 Jan 2012 12:30:50 -0800 (PST)
From: Pradeep Patra <smilesonisamal@gmail.com>
Subject: Collecting specific values from hash reference
Message-Id: <3472868e-e3fe-4a55-aaba-32e54e5a1bbb@f11g2000yql.googlegroups.com>
Hi,
I have a hash reference as follows:
$VAR1 = {
A.processor0.error => 0
A.processor0.success => 77
A.processor0.total => 77
A.processor1.error => 0
A.processor1.success => 57
A.processor1.total => 57
A.processor2.error => 0
A.processor2.success => 110
A.processor2.total => 110
}
I want to collect the values from the different processors(for exp:
success value of processor0,processor1,processor2 and sum them i.e 77
+ 57 +110 = 244 ).and store in a variable $success.
If ($success == 244)
{
return 1;
} else {
return 0;
}
Can anybody help me in this regard?
Regards
Pradeep
------------------------------
Date: Fri, 20 Jan 2012 20:11:07 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: perl syntax check
Message-Id: <slrnjhjiir.26l.willem@toad.stack.nl>
Helmut Richter wrote:
) On Fri, 20 Jan 2012, Ben Morrow wrote:
)
)> Assuming this is CGI::Carp, that output is almost certainly coming from
)> the __DIE__ handler. This is running because perl is dieing at compile
)> time, due to there being a fatal compile-time error (probably a syntax
)> error) somewhere in the code. If the code were correct it would stop
)> without producing any output.
)
) Yes, it is certainly from "use CGI::Carp qw(fatalsToBrowser);" which I use
) while debugging -- later without the fatalsToBrowser. It works fine for
) errors at run time but not at compile time. It would be nice it did, just
) sending the syntax errors to the browser screen, but it doesn't: the
) browser gets an error 500 and the syntax errors go to the Nirwana.
Odd, it's supposed to send the compile time errors as well.
Have you turned off 'pretty errors' in your browser?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Sat, 21 Jan 2012 13:10:39 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Perl versions in the wild (was: When is @_ undefined?)
Message-Id: <slrnjhlapv.et3.hjp-usenet2@hrunkner.hjp.at>
On 2012-01-20 19:01, Shmuel Metz <spamtrap@library.lspace.org.invalid> wrote:
> Well, while I'm currently using 5.10.0, there are people stuck with
> 5.8[1].
[...]
> [1] Stuck with ear;ier versions? I'm not sure that I'm strong
> enough for the answer.
A little statistic from some servers I administrate:
count version
----- -------
2 5.00503
4 5.8.0
4 5.8.5
11 5.8.8
6 5.10.0
6 5.10.1
1 5.12.3
But I admit that this is somewhat misleading: I am not stuck with those
versions, I can install a newer version on any of those machines if I
need to, and some of those machines do have a newer version of perl in
/usr/local in addition to the version shown above.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Sat, 21 Jan 2012 12:19:22 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: ssh tunnel
Message-Id: <slrnjhl7pq.et3.hjp-usenet2@hrunkner.hjp.at>
On 2012-01-17 11:46, Ben Morrow <ben@morrow.me.uk> wrote:
> Try system("ssh -f -L... ... sleep 10") instead of open3. It's important
> with -f to use 'sleep 10' rather than -N, otherwise the ssh process will
> never exit. (It doesn't seem to be very easy to find its pid to kill it
> manually.)
open($fh, '-|', ...) returns the pid, so does fork. The following script
works for me, at least on linux:
#!/usr/bin/perl
use warnings;
use strict;
use IO::Socket::INET;
$| = 1;
print "opening tunnel ... ";
my $pid = open(my $fh, '-|',
'ssh', '-N', 'hjp@mri.DOMAIN', '-L', '10007:chronos.DOMAIN:7'
) or die;
print " done (pid=$pid)\n";
sleep 5;
system('lsof', '-i', ':10007');
sleep 5;
print "opening socket ... ";
my $sock = IO::Socket::INET->new(PeerHost => 'localhost',
PeerPort => 10007,
Proto => 'tcp');
print " done\n";
print "sending request ... ";
print $sock "test123\n";
print " done\n";
print "reading response ... ";
my $resp = <$sock>;
print " done (resp = $resp)\n";
print "closing socket ... ";
close($sock);
print " done\n";
sleep(5);
system('lsof', '-i', ':10007');
sleep(5);
print "closing tunnel ... ";
kill(15, $pid);
my $rc = waitpid($pid, 0);
print " done (rc = $rc)\n";
sleep(5);
system('lsof', '-i', ':10007');
__END__
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Sat, 21 Jan 2012 17:35:45 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: ssh tunnel
Message-Id: <hk9ru8-5i51.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2012-01-17 11:46, Ben Morrow <ben@morrow.me.uk> wrote:
> > Try system("ssh -f -L... ... sleep 10") instead of open3. It's important
> > with -f to use 'sleep 10' rather than -N, otherwise the ssh process will
> > never exit. (It doesn't seem to be very easy to find its pid to kill it
> > manually.)
>
> open($fh, '-|', ...) returns the pid, so does fork. The following script
> works for me, at least on linux:
I think you're not realising what the -f argument to ssh does. It makes
ssh put itself in the background, but only after any possible need to
prompt the user has been dealt with. So if you run ssh -f from Perl in
the foreground (with system(), rather than with open/2/3, and without
explicitly forking first), the user will see any necessary prompts about
accepting host keys (or even passwords, if you're using password auth)
and then ssh will go into the background and the system() call will
return to Perl.
It's very convenient, when that's the behaviour you want, but
unfortunately since ssh forked itself into the background there's no way
to find out the (new) pid of the background ssh process. Fortunately ssh
won't exit until all the forwardings it set up are no longer in use, so
a command of 'sleep 10' gives your Perl program 10 seconds to open a
forwarded connection, and then ssh will stay running until it closes. If
you'd used -N instead the backgrounded ssh would never exit on its own.
Ben
------------------------------
Date: Sat, 21 Jan 2012 19:31:49 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: ssh tunnel
Message-Id: <slrnjhm14l.5cl.hjp-usenet2@hrunkner.hjp.at>
On 2012-01-21 17:35, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>> On 2012-01-17 11:46, Ben Morrow <ben@morrow.me.uk> wrote:
>> > Try system("ssh -f -L... ... sleep 10") instead of open3. It's important
>> > with -f to use 'sleep 10' rather than -N, otherwise the ssh process will
>> > never exit. (It doesn't seem to be very easy to find its pid to kill it
>> > manually.)
>>
>> open($fh, '-|', ...) returns the pid, so does fork. The following script
>> works for me, at least on linux:
>
> I think you're not realising what the -f argument to ssh does. It makes
> ssh put itself in the background, but only after any possible need to
> prompt the user has been dealt with.
Yes, but there is no reason to use it. Perl can put processes in the
"background" just fine. You will notice that my little test program
doesn't use it.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Sat, 21 Jan 2012 20:49:15 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: ssh tunnel
Message-Id: <bvkru8-0ag1.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2012-01-21 17:35, Ben Morrow <ben@morrow.me.uk> wrote:
> > Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> >> On 2012-01-17 11:46, Ben Morrow <ben@morrow.me.uk> wrote:
> >> > Try system("ssh -f -L... ... sleep 10") instead of open3. It's important
> >> > with -f to use 'sleep 10' rather than -N, otherwise the ssh process will
> >> > never exit. (It doesn't seem to be very easy to find its pid to kill it
> >> > manually.)
> >>
> >> open($fh, '-|', ...) returns the pid, so does fork. The following script
> >> works for me, at least on linux:
> >
> > I think you're not realising what the -f argument to ssh does. It makes
> > ssh put itself in the background, but only after any possible need to
> > prompt the user has been dealt with.
>
> Yes, but there is no reason to use it. Perl can put processes in the
> "background" just fine. You will notice that my little test program
> doesn't use it.
Perl can put processes in the background just fine, yes. That's not the
issue. The issue is that sometimes ssh needs to prompt, and running it in
the background from Perl doesn't handle that very well.
I took the program you posted and made the following change:
@@ -16,7 +16,8 @@
$| = 1;
print "opening tunnel ... ";
my $pid = open(my $fh, '-|',
- 'ssh', '-N', 'hjp@mri.DOMAIN', '-L', '10007:chronos.DOMAIN:7'
+ 'ssh', '-N', '-oUserKnownHostsFile=/dev/null',
+ 'isis', '-L', '10007:isis:7'
) or die;
print " done (pid=$pid)\n";
Apart from changing the host to one I have ssh access to, this sets
UserKnownHostsFile=/dev/null so ssh will always ask me to verify the
host key. If I run this, and I take more than 10 seconds to reply to the
prompt, the connection isn't set up properly and the program hangs
(script session wrapped for Usenet):
Script started on Sat Jan 21 20:28:55 2012
perl -x hjp-ssh
opening tunnel ... done (pid=49176)
The authenticity of host 'isis.morrow.me.uk (204.109.63.142)' can't
be established.
RSA key fingerprint is ee:8b:2a:da:6f:34:30:16:bf:84:85:50:f7:d6:7a:6f.
Are you sure you want to continue connecting (yes/no)? opening socket
... done
sending request ... Can't use an undefined value as a symbol reference
at hjp-ssh line 25.
^C
Script done on Sat Jan 21 20:29:40 2012
Obviously the 10 seconds' grace is a rather artificial feature of that
test program, and normally it would plough straight on without giving
the user any opportunity to respond.
If, instead, I make this change:
@@ -15,10 +15,12 @@
$| = 1;
print "opening tunnel ... ";
-my $pid = open(my $fh, '-|',
- 'ssh', '-N', 'hjp@mri.DOMAIN', '-L', '10007:chronos.DOMAIN:7'
- ) or die;
-print " done (pid=$pid)\n";
+system(qw!
+ ssh -f -oUserKnownHostsFile=/dev/null
+ isis -L 10007:isis:7
+ sleep 10
+!) == 0 or die;
+print "ssh succeeded ... ";
sleep 5;
system('lsof', '-i', ':10007');
@@ -44,15 +46,7 @@
sleep(5);
system('lsof', '-i', ':10007');
-sleep(5);
-
-print "closing tunnel ... ";
-kill(15, $pid);
-my $rc = waitpid($pid, 0);
-print " done (rc = $rc)\n";
-sleep(5);
-system('lsof', '-i', ':10007');
__END__
hp
it will wait at the prompt until the user responds, and then continue
properly (I waited more than 10 seconds before typing 'yes'):
Script started on Sat Jan 21 20:29:55 2012
perl -x hjp-ssh-f
opening tunnel ... The authenticity of host 'isis.morrow.me.uk
(204.109.63.142)' can't be established.
RSA key fingerprint is ee:8b:2a:da:6f:34:30:16:bf:84:85:50:f7:d6:7a:6f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'isis.morrow.me.uk' (RSA) to the list of
known hosts.
ssh succeeded ... COMMAND PID USER FD TYPE DEVICE
SIZE/OFF NODE NAME
ssh 49204 mauzo 4u IPv6 0xffffff002c08b000 0t0 TCP
localhost:10007 (LISTEN)
ssh 49204 mauzo 5u IPv4 0xffffff002b228000 0t0 TCP
localhost:10007 (LISTEN)
opening socket ... done
sending request ... done
reading response ... channel 3: open failed: connect failed: Connection
refused
Use of uninitialized value $resp in concatenation (.) or string at
hjp-ssh-f line 31.
done (resp = )
closing socket ... done
Script done on Sat Jan 21 20:30:37 2012
It fails later, obviously, because there's nothing listening at the
remote end, but having failed both the Perl script and the ssh process
exit cleanly.
Ben
------------------------------
Date: Fri, 20 Jan 2012 19:14:25 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: When is @_ undefined?
Message-Id: <20120120111348.715@kylheku.com>
On 2012-01-20, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth Kaz Kylheku <kaz@kylheku.com>:
>> On 2012-01-20, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>> > tmcd@panix.com (Tim McDaniel) writes:
>> >> Ben Morrow <ben@morrow.me.uk> wrote:
>> >>>I think that was Rainer's point: Perl variables are never 'undefined' in
>> >>>the sense of the C standard, so the 'uninitialized value' warnings tend
>> >>>to be more noise than useful. They certainly aren't equivalent to the
>> >>>'variable used without being assigned a value' warnings C compilers are
>> >>>so fond of, which often do indicate genuine bugs.
>> >>
>> >> Using a variable without it having been assigned a value may indeed
>> >> be a genuine bug.
>> >
>> > Using a variable after some value was assigned to it may also be a
>> > genuine bug.
>> >
>> > It all depends on the value and how it is supposed to be
>> > used. Everything might be an error, provided the context is unknown.
>>
>> Uses of uninitialized variables are erroneous regardless of context.
>
> In Perl or in C? In C you are correct, in Perl you are incorrect.
In any language, including the one in your head that you program in
before typing out the code in a concrete language.
------------------------------
Date: Fri, 20 Jan 2012 19:32:18 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: When is @_ undefined?
Message-Id: <87sjjaw4ot.fsf@sapphire.mobileactivedefense.com>
Kaz Kylheku <kaz@kylheku.com> writes:
> On 2012-01-20, Ben Morrow <ben@morrow.me.uk> wrote:
>> Quoth Kaz Kylheku <kaz@kylheku.com>:
>>> On 2012-01-20, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>> > tmcd@panix.com (Tim McDaniel) writes:
>>> >> Ben Morrow <ben@morrow.me.uk> wrote:
>>> >>>I think that was Rainer's point: Perl variables are never 'undefined' in
>>> >>>the sense of the C standard, so the 'uninitialized value' warnings tend
>>> >>>to be more noise than useful. They certainly aren't equivalent to the
>>> >>>'variable used without being assigned a value' warnings C compilers are
>>> >>>so fond of, which often do indicate genuine bugs.
>>> >>
>>> >> Using a variable without it having been assigned a value may indeed
>>> >> be a genuine bug.
>>> >
>>> > Using a variable after some value was assigned to it may also be a
>>> > genuine bug.
>>> >
>>> > It all depends on the value and how it is supposed to be
>>> > used. Everything might be an error, provided the context is unknown.
>>>
>>> Uses of uninitialized variables are erroneous regardless of context.
>>
>> In Perl or in C? In C you are correct, in Perl you are incorrect.
>
> In any language, including the one in your head that you program in
> before typing out the code in a concrete language.
But 'a variable which didn't have an initial values assigned to it' is
not necessarly 'an uninitialized variable' in the sense that its value
is 'indeterminate' (and using it 'undefined behaviour'). Eg, in C, all
file-scope variables are initialized to a 'null value' of some
appropriate type and in Perl, this is true for all variables.
------------------------------
Date: Fri, 20 Jan 2012 20:14:26 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: When is @_ undefined?
Message-Id: <slrnjhjip2.26l.willem@toad.stack.nl>
Ben Morrow wrote:
)
) Quoth Kaz Kylheku <kaz@kylheku.com>:
)> Uses of uninitialized variables are erroneous regardless of context.
)
) In Perl or in C? In C you are correct, in Perl you are incorrect.
In C, static variables don't need to be explicitly initialized:
They're initialized to 0 if you don't provide a value.
In Perl, variables don't nee to be explicitly initialized:
They're initialized to undef if you don't provice a value.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Fri, 20 Jan 2012 20:22:25 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: When is @_ undefined?
Message-Id: <jfcie1$oed$1@reader1.panix.com>
In article <slrnjhjip2.26l.willem@toad.stack.nl>,
Willem <willem@toad.stack.nl> wrote:
>In Perl, variables don't nee to be explicitly initialized:
>They're initialized to undef if you don't provice a value.
To be more precise, in Perl *scalar* variables are initialized to
undef, but arrays and hashes are initialized to have no elements,
bareword filehandles are initialized to be unopened (so you may get
messages like "readline() on unopened filehandle FOO at -e line 1."),
and there may be other types of object that are initialized
differently.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Fri, 20 Jan 2012 21:48:29 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: When is @_ undefined?
Message-Id: <20120120132711.761@kylheku.com>
On 2012-01-20, Willem <willem@toad.stack.nl> wrote:
> Ben Morrow wrote:
> )
> ) Quoth Kaz Kylheku <kaz@kylheku.com>:
> )> Uses of uninitialized variables are erroneous regardless of context.
> )
> ) In Perl or in C? In C you are correct, in Perl you are incorrect.
>
> In C, static variables don't need to be explicitly initialized:
> They're initialized to 0 if you don't provide a value.
In C, if you refer to a variable that you have not declared there
will be a compile-time error.
C catches uses of nonexistent variables.
Local variables can exist (as well as dynamic objects) that have indeterminate
contents, which is a different matter.
> In Perl, variables don't nee to be explicitly initialized:
> They're initialized to undef if you don't provice a value.
But this happens when you merely mention a variable that has not been seen
before; i.e. hitherto does not exist.
I.e. yes the value is not uninitialized because the variable at that point
instantly comes into existence with a defined value. But this is actually a
misfeature which hides the bigger problem that the variable did not exist prior
to that use!
The competent program designer recgonizes this situation as an error, and
regards the default behavior of just instantiating the variable and giving it
an initial value is a dangerous misfeature.
You can get Perl to diagnose the situation, and then the default value of the
variable is moot.
------------------------------
Date: Sat, 21 Jan 2012 10:03:27 +0000 (UTC)
From: Willem <willem@toad.stack.nl>
Subject: Re: When is @_ undefined?
Message-Id: <slrnjhl3bf.2n4.willem@toad.stack.nl>
Kaz Kylheku wrote:
) On 2012-01-20, Willem <willem@toad.stack.nl> wrote:
)> Ben Morrow wrote:
)> )
)> ) Quoth Kaz Kylheku <kaz@kylheku.com>:
)> )> Uses of uninitialized variables are erroneous regardless of context.
)> )
)> ) In Perl or in C? In C you are correct, in Perl you are incorrect.
)>
)> In C, static variables don't need to be explicitly initialized:
)> They're initialized to 0 if you don't provide a value.
)
) In C, if you refer to a variable that you have not declared there
) will be a compile-time error.
)
) C catches uses of nonexistent variables.
)
) Local variables can exist (as well as dynamic objects) that have indeterminate
) contents, which is a different matter.
It is the latter matter that I was concerned with, as were the posters
before me. Note the phrase "uninitialized variables". It does not say
"undeclared variables".
)> In Perl, variables don't need to be explicitly initialized:
)> They're initialized to undef if you don't provice a value.
)
) But this happens when you merely mention a variable that has not been seen
) before; i.e. hitherto does not exist.
Doesn't everybody use strict these days?
) You can get Perl to diagnose the situation, and then the default value of the
) variable is moot.
There is a diagnostic for using an *undeclared* _variable_ (which turns into
a compile time error), and there is a completely different diagnostic for
using an *undefined* _value_, which is a runtime warning.
So no, the default value of an uninitialized variable is not moot even if
you turn on diagnostics for undeclared variables.
Uninitialized, undeclared, uninitialized, undeclared. Not remotely the same.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Sat, 21 Jan 2012 12:53:34 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: When is @_ undefined?
Message-Id: <slrnjhl9pu.et3.hjp-usenet2@hrunkner.hjp.at>
On 2012-01-19 22:57, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
>> In <87ehuv3h8y.fsf@sapphire.mobileactivedefense.com>, on 01/19/2012
>> at 02:21 PM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
>>
>> >Because he has successfully been fooled into believing that Perl
>> >variables don't start to exist in some well-defined state by the 'use
>> >of uninitialized value!' warning.
>>
>> Isn't undef a well defined state?
>
> I think that was Rainer's point: Perl variables are never 'undefined' in
> the sense of the C standard,
Nitpick: The C standard never talks about "undefined variables", only
about "undefined behaviour". The value of a variable which hasn't been
(explicitely or implicitely) initialized ist "indeterminate".
> so the 'uninitialized value' warnings tend to be more noise than
> useful. They certainly aren't equivalent to the 'variable used without
> being assigned a value' warnings C compilers are so fond of, which
> often do indicate genuine bugs.
The 'uninitialized' warnings are badly worded. The warning really means
"you are using the value «undef» in a context where a defined value is
expected".
> In perl's defence, they were much more useful back before 'my' and
> 'strict' were invented. In Perl 4 it was terribly easy to misspell a
> variable name, and the only notice you got was (if you were lucky) an
> 'uninitialized value' warning. IMHO in Perl 5 they are redundant.
I don't think they are redundant. They are useful in cases where the
programmer thinks that a value should be defined but for some reason it
isn't. This usually indicates a bug.
Of course there are also situations in which the programmer *does*
expect a value to be undef and wants to treat it as '' or 0 - then it's
not a bug and the warning should be turned off. The 'uninitialized'
warning is certainly the warning I turn off most frequently. (The second
one is 'recursion' - if there are any others that I turn off, I do that
so infrequently I don't remember them).
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Sat, 21 Jan 2012 12:57:34 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: When is @_ undefined?
Message-Id: <slrnjhla1e.et3.hjp-usenet2@hrunkner.hjp.at>
On 2012-01-20 18:32, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth Kaz Kylheku <kaz@kylheku.com>:
>> On 2012-01-20, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>> > tmcd@panix.com (Tim McDaniel) writes:
>> >> Ben Morrow <ben@morrow.me.uk> wrote:
>> >>>I think that was Rainer's point: Perl variables are never 'undefined' in
>> >>>the sense of the C standard, so the 'uninitialized value' warnings tend
>> >>>to be more noise than useful. They certainly aren't equivalent to the
>> >>>'variable used without being assigned a value' warnings C compilers are
>> >>>so fond of, which often do indicate genuine bugs.
>> >>
>> >> Using a variable without it having been assigned a value may indeed
>> >> be a genuine bug.
>> >
>> > Using a variable after some value was assigned to it may also be a
>> > genuine bug.
>> >
>> > It all depends on the value and how it is supposed to be
>> > used. Everything might be an error, provided the context is unknown.
>>
>> Uses of uninitialized variables are erroneous regardless of context.
>
> In Perl or in C? In C you are correct, in Perl you are incorrect.
In Perl it isn't possible to use an uninitialized variable. Ex falso
quodlibet.
(but note that Tim wrote "assigned", not "initialized")
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Sat, 21 Jan 2012 06:10:35 -0800
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: When is @_ undefined?
Message-Id: <86ipk5b0ys.fsf@red.stonehenge.com>
>>>>> "Peter" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
>> In Perl or in C? In C you are correct, in Perl you are incorrect.
Peter> In Perl it isn't possible to use an uninitialized variable. Ex falso
Peter> quodlibet.
Ehh, what?
my $x;
print 3 + $x; # using an uninitialized variable... very possible!
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
------------------------------
Date: Sat, 21 Jan 2012 19:46:58 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: When is @_ undefined?
Message-Id: <slrnjhm212.5cl.hjp-usenet2@hrunkner.hjp.at>
On 2012-01-21 14:10, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>>>>>> "Peter" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
>>> In Perl or in C? In C you are correct, in Perl you are incorrect.
>
>Peter> In Perl it isn't possible to use an uninitialized variable. Ex falso
>Peter> quodlibet.
>
> Ehh, what?
>
> my $x;
At this point $x is initialized to the value undef.
> print 3 + $x; # using an uninitialized variable... very possible!
So you aren't using an uninitialized variable here.
Contrast this with
int f(void) {
int x;
return x;
}
in C. Here the variable x is not initialized and its value is
indeterminate: It contains whatever bit pattern happened to be in the
memory location or register occupied by x (this might even be an invalid
pattern causing an exception the first time you try to use the value).
On the other hand, in
int f(void) {
static int x;
return x;
}
x *is* implicitly initialized to 0. The function is guaranteed to return
0, just like in Perl the function
sub {
my $x;
return $x;
}
is guaranteed to return undef.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Sat, 21 Jan 2012 20:53:46 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: When is @_ undefined?
Message-Id: <q7lru8-0ag1.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2012-01-21 14:10, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> >>>>>> "Peter" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
> >>> In Perl or in C? In C you are correct, in Perl you are incorrect.
> >
> >Peter> In Perl it isn't possible to use an uninitialized variable. Ex falso
> >Peter> quodlibet.
> >
> > Ehh, what?
> >
> > my $x;
>
> At this point $x is initialized to the value undef.
You are attempting to apply the meanings of words as used in the C
standard to Perl, where they don't apply.
~% perl -we'my $x; print $x + 0'
Use of uninitialized value $x in addition (+) at -e line 1.
The term 'uninitialized value', as applied to Perl, means a scalar
containing undef.
Ben
------------------------------
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 3597
***************************************
