First, let's simplify your code a bit.

In the .pl file, replace

use Cwd;
use File::Basename;

BEGIN {
  my $dir = dirname($0);
  my $path;
  if ($dir =~ /^\//) {
    #--absolute path
    $path = $dir;
  } elsif ($dir eq ".") {
    #-- relative, current dir
    $path = getcwd();
  } else {
    #-- relative, but not from current dir
    $dir =~ s/^\.\///;
    $path = getcwd()."/$dir";
  }
  unshift(@INC, "$path/lib");
  unshift(@INC, "$path/lib-perl");
  unshift(@INC, "$path/lib-perl/sun4-solaris-64int");
}
[download]

use Cwd qw( realpath ); 
use File::Basename;

my $script_dir; BEGIN { $script_dir = dirname(realpath($0)); }

use lib "$script_dir/lib", "$script_dir/lib-perl";
[download]

In the .pm files, remove the following

use File::Basename;
use Cwd;

BEGIN {
  my $dir = dirname($0);
  my $path;
  if ($dir =~ /^\//) {
    #--absolute path
    $path = $dir;
  } elsif ($dir eq ".") {
    #-- relative, current dir
    $path = getcwd();
  } else {
    #-- relative, but not from current dir
    $dir =~ s/^\.\///;
    $path = getcwd()."/$dir";
  }
  unshift(@INC, "$path/lib");
  unshift(@INC, "$path/lib-perl");
}
[download]

It makes no sense to tell perl where to find the library after it's already been found!

Now on to your question.

To determine the presence of an element I use the statement defined($ntCapabilities{$type}{'SW_PAR'}).

From where? The .pl file? There is no such variable there. You would have to export %ntCapabilities in order to do that (and roll out your own import since no module will help you export a lexical variable).

But since exporting variables (as oppose to functions) is rather fishy, it would be better to create an accessor (sub is_capable?) and export the accessor from Capability or use its full name.

if (Capability::is_capable(...)) {
    ...
}
[download]

Thanks for the cleanup tip. Now on your question: the call defined($ntCapabilities{$type}{'SW_PAR'} is only done in Capability.pm, nowhere else.

I requested that you show us sufficient code to demonstrate the problem, but no more than that.

Your failed on both counts. You did not post sufficient code to demonstrate the problem, and you posted extraneous code that prevents us from running your code and distracts from the issue at hand.

$ntCapabitilies needs to be declared using our if you want to share its data between modules. The function is working presumably because it was defined in the same namespace as $ntCapabilities and hence can see its data. The accessor method is in a different namespace (Octopus?) and so can't see its data, even if you import the name. into the other namespace. This is because the imported variable is a package ("our") variable rather than a lexically scoped ("my") variable. All your values were assigned to the "my" variable, not the "our" variable.

Two other points:

One really should use warnings, not just strict. If you don't like all the warnings that use warnings; spews out, then clean up the code that is causing them. Getting rid of it to quiet the warnings is only going to cause you a world of trouble. If you have a very specific reason to do something normally warned about (e.g. you need to munge the symbol table), then turn off a specific warning for a specific block. Turning of warnings globally is a bad idea. Someone is paying you a lot of money to develop this code. It is important to give yourself every chance possible to catch mistakes.

You and your team could have done a much better job of reducing this code to the essentials than you did. For example,

• you could remove all data from $ntCapabilities except one or two elements needed to show the problem.
• you could remove all "use" and "require" statements except the ones causing the problem. We don't have your family of modules and can't reliably run your code to see how it works on our system if you leave those extra "use" and "require" statements in.

Best, beth

I've worked in environments (including the current one) whereby, entirely due to legacy reasons, cleaning up the code from a warning(s) POV, is not feasible with in the constraints of the project at hand - indeed, it would require a self-contained project to totally clean up the code.

The end result being that, wheresoever legacy code had/has to be used (pun intended) from within well-behaved code, it was/is done within a local block in order to circumvent the multifarious warnings that would otherwise be generated i.e.

{
    no warnings;
    use Legacy::Module;
}
[download]

The removal of the warnings from the legacy code can then be done in piece-meal fashion as a background task without compromising the aggressive timescales for the new code.
A user level that continues to overstate my experience :-))

In this case it was not an issue. All perl scripts were run using -w. Changing that to include use warnings 'all' rather the using #!/usr/bin/perl -w did not result in more warnings neither at compile time nor at run-time (for me warnings are an indication of a possible coding error).

Hi, Thanks, but all scrips contain the shebang

#!/usr/bin/perl -w
[download]

Isn't that the same as use warnings?

No it isn't, see perllexwarn