Are you positive that you have given us correct information? The reason I ask is that the warning you are getting doesn't even jive with the code you've shown us.

Use of uninitialized value in string eq at ./pancho-ini line 1430.

That states the unitialized value is being used in a "string eq". The only string eq you have in the code you've shown us is on line 1434. Is that your actual code? (Do you really have sub called "foo"?

-sauoq
"My two cents aren't worth a dime.";

Yes. Its the real deal. I've been hunting and pecking for and "eq" in my code, even near line 1430, and its just not there.

1434   if ($args->{src} && $args->{src} eq "commit") {
[download]

-Blake

No line 1434 can't be the troublemaker because with or without warnings, undef ne 'commit'. The result of this boolean test would be false, and nothing would be printed. And as you can see, there is printout from this block:

I've got my sources!
I'm committed!
[download]

To the op: use Data::Dumper, and print out what's in the dubious variables (here: $arg). If this sub is called a lot without any warnings, then it's better to restrict output to when it is actually useful. For that, I sometimes do things like:

use Data::Dumper;
local $SIG{__WARN__} = sub { print STDERR @_, Dumper $arg };
[download]

You must put that where $arg is in scope, thus in the sub, and it needs to be run before the warning happens.

Also, print out the line number perl thinks it's on, it's in __LINE__. Sometimes it's off from the actual line number by 1, maybe sometimes even more (though I don't think I've ever seen that happen).

The line numbering seems to drift when your statement itself is more than one line, or on occasion when the if call is labelled the culprit, when it's actually a line of code in the if-BLOCK. So, it seems that 1431 is the problem, not 1430, and yet, no output is produced to support of that theory.

This doesn't explain your error message, but it does highlight a couple of problems with your code that could be a contributory factors.

#! perl -w
use strict;
my $args = { src=>'commit' };

if ($args->{err}) { print "There is a problem : $args->{err}\n"; }

if ($args->{src} eq "commit") {
    print "I've got my sources!\n";
    print "I'm committed!\n" if (!$args->{err});
}
__END__
# Output
C:\test>192192
I've got my sources!
I'm committed!
[download]

You''ll notice that there is no key 'err' defined in the hash, and that, "I'm commited" was printed.

If I modify this as follows:

#! perl -w
use strict;
my $args = { src=>'commit' };

if ( exists $args->{err} && $args->{err} ) { print "There is a problem
+ : $args->{err}\n"; }

if ($args->{src} eq "commit") {
    print "I've got my sources!\n";
    print "I'm committed!\n" if (!exists $args->{err} && !$args->{err}
+);
}
__END__
# Output
C:\test>192192
I've got my sources!
[download]

This time, the "I'm commited" wasn't printed!

The reason for this is autovivifcation. Even testing for the presence of a hash element if you do it in any other way than using exists. Even doing if (defined $args->{key}) {...} will cause the key to 'spring into existance'.

Another clue to your error message is that coding if ($somevar) is semantically similar to doing if ( $somevar ne '' ) and the test is probably translated as such by the compiler.

Changing your code to use exists key && key may make your warning go away.

I did have a thought that if the reference being shifted into $args is a bless'd reference, the source of the warning might lie outside your code in the blessing package, but my knowledge of Perl's OO stuff is still in it's infancy, so I can't add anything to the thought.

use Data::Dumper; print Dumper($args);

I'm using 5.6.1. and Dumper (doh! i forgot about what a great tool this is!) shows:

$VAR1 = {
          'path' => '',
          'desc' => 'Cisco Internetwork Operating System Software 
IOS (tm) C2600 Software (C2600-I-M), Version 12.0(7)T,  RELEASE SOFTWA
+RE (fc2)
Copyright (c) 1986-1999 by cisco Systems, Inc.
Compiled Tue 07-Dec-99 02:12 by phanguye',
          'utftp' => 'TFTP.LUNARMEDIA.LAB,
          'host' => 'ROUTER',
          'tftp' => '10.12.71.130',
          'src' => 'commit',
          'file' => 'router.cfg',
          'err' => ''
        };
[download]

Oddly, this is what I believe that it *should* be returning. the Net::SNMP docs show that error() will return empty if there is no error found. Does this output make more sense for anyone else? It just seems to validate the confusion for me.

Thanks VERY much -c

You may have already tried this, but when I've run into this kind of test, I end up writing the clunky:

...
   if ( defined $args->{err} and $args->{err} ) {
      print "There is a problem : $args->{err}\n";
   }
...
[download]

HTH

-Ducky