Re: Use of uninitialized value
by jasonk (Parson) on Feb 28, 2007 at 15:41 UTC
|
Use of uninitialized value%s
(W uninitialized) An undefined value was used as if it were already
defined. It was interpreted as a "" or a 0, but maybe it was a
mistake. To suppress this warning assign a defined value to your
variables.
To help you figure out what was undefined, perl tells you what
operation you used the undefined value in. Note, however, that
perl optimizes your program and the operation displayed in the
warning may not necessarily appear literally in your program. For
example, "that $foo" is usually optimized into ""that " . $foo",
and the warning will refer to the "concatenation (.)" operator,
even though there is no "." in your program.
| We're not surrounded, we're in a target-rich environment! |
|---|
| [reply] |
Re: Use of uninitialized value
by davorg (Chancellor) on Feb 28, 2007 at 15:44 UTC
|
If you add "use diagnostics" to your code, then Perl will tell you _exactly_ what it means.
| [reply] |
Re: Use of uninitialized value
by andye (Curate) on Feb 28, 2007 at 15:57 UTC
|
Angharad,
A 'string' is a variable with some text in it.
But yours doesn't have anything in it, it's empty.
It's empty because you haven't put anything in it.
On whatever line the error's coming up, Perl is expecting that there should be something in it.
Perl is warning you that you could have made a mistake.
Here's an example that produces the same error:
use warnings;
my $foo;
if ($foo eq "hey!") {
print "yes"
}
Here Perl complains about an uninitialised value, because I'm checking to see if $foo equals "yes" when I haven't put anything at all in $foo. If I started off by saying my $foo = 'no' or even my $foo = '' then the warning wouldn't appear.
Hope that helps.
andye
(by the way: sorry if any of this sounds patronising: your question was pretty short so I couldn't tell what you already knew, so I thought it better to start from first principles as much as I could. Hope that's OK).
| [reply] [d/l] [select] |
Re: Use of uninitialized value
by johngg (Canon) on Feb 28, 2007 at 16:28 UTC
|
These two snippets run from the command line show the difference between just declaring a scalar and initialising it to an empty string. Running under use warnings, the first snippet generates the message, the second doesn't as the string has been initialised.
$ perl -e '
> use strict;
> use warnings;
> my $string;
> print qq{>$string<\n};'
Use of uninitialized value in concatenation (.) or string at -e line 5
+.
><
$ perl -e '
> use strict;
> use warnings;
> my $string = q{};
> print qq{>$string<\n};'
><
$
I hope this illustrates the difference.
Cheers, JohnGG | [reply] [d/l] [select] |
Re: Use of uninitialized value
by kyle (Abbot) on Feb 28, 2007 at 15:43 UTC
|
| [reply] |
Re: Use of uninitialized value
by Angharad (Pilgrim) on Feb 28, 2007 at 16:24 UTC
|
Thanks for your help so far.
The offending line is something like this
$item = "$code[0]" . "."."$code[1]" . ".". "$code[2]";
Any comments appreciated | [reply] [d/l] |
|
|
Erm . . . ouch.
- The quotes around "$code[0]" are superfluous, to start
- You could have just written it as "$code[0].$code[1].$code[2]" in one swell foop
- Of course that locks you in to a fixed number of elements; if you want to join an arbitrary number of items in @code then just use join: $item = join( ".", @code );
| [reply] [d/l] [select] |
|
|
If want a specific subset of elements, then you can use a slice:
my $item = join( ".", @code[0..2] );
my $not_item = join( ".", @code[9,7,0,3] );
| [reply] [d/l] |
|
|
| [reply] [d/l] |
|
|
|
|
|
|
|
One or more of ($code[0], $code[1], $code[2]) has nothing in it.
Best,
andye
| [reply] [d/l] |
| A reply falls below the community's threshold of quality. You may see it by logging in. |