Start by not using a global var (*SNMP). If you insist, at least localize it. If it ceases to exist, it's hard for it to be "jammed".

Fixed along with *many* other problems:

sub {
    my ($target, $table, $fieldstring, $comstr) = @_;

    my @cmd = ( mibtable => (
        -table  => $table,
        -fields => $fieldstring,
        -node   => $target,
    );

    open(my $fr_child, '-|', @cmd)
        or die("Can't launch $cmd[0]: $!\n");

    while (<$fr_child>) {
        # do stuff
    }

    close($fr_child)
        or die("Can't wait for child: $!\n");

    die("Child died from signal ", ($? & 0x7F), "\n") if $? & 0x7F;
    die("Child died with code ",   ($? >> 8),   "\n") if $? >> 8;

    print("Child exited successfully\n");
}
[download]

Thanks, I tried some of these changes to the 'open' line, but problems still choke the process:

$pid = open( my $fr_child, '-|', @cmd) 
            or die("Can't launch $cmd[0]: $!\n");
[download]

fails with an error: Can't use an undefined value as filehandle reference at testSnmp2.pl line 192.

Tweaked to look like this

$pid = open( my $fr_child, '-|', $snmpCmd)
            or die("Can't launch $cmd[0]: $!\n");
[download]

The open succeeds, but I get this error from the child proc

Child exited successfully
!!!! Illegal seek / 0 /
[download]

and I get no data back.

Tweaked again to be

        $pid = open( my $fr_child, $snmpCmd)
            or die("Can't launch $cmd[0]: $!\n");
[download]

I get the following response: Can't wait for child: with an $? value of 256.

If it helps, I'm running on Solaris 8.

I just noticed the 5.6 limit now. That explains some of the reasons my code won't do for you.

Reverting to using $snmpCmd is wrong though. Sure, you'll need to provide the command as a string in 5.6, but you don't properly convert the args into shell literals at the moment.

Nothing in my code can output "!!!! Illegal seek / 0 /", so I don't know anything about that.

I get the following response: Can't wait for child: with an $? value of 256.

Looks like there's a bug in Perl's design. There's no reliable way to tell if close returns a system error ($!) or a child error ($?)*.

( On second thought, we'll get the wrong error message at worse, so I will use $!==0 )

sub to_shell_literal {
    my ($s) = @_;
    #return $s if m{^[a-zA-Z0-9/_-]+\z};
    $s =~ s/'/'\\''/g;
    return "'$s'";
}

sub {
    my ($target, $table, $fieldstring, $comstr) = @_;

    my @cmd = ( mibtable => (
        -table  => $table,
        -fields => $fieldstring,
        -node   => $target,
    );

    my $cmd = join ' ', map to_shell_literal($_), @cmd;

    open(my $fr_child, "$cmd |")
        or die("Can't launch $cmd[0]: $!\n");

    while (<$fr_child>) {
        # do stuff
    }

    if (!close($fr_child)) {
        die("Can't wait for child: $!\n") if $! != 0;
        die("Child died from signal ", $? & 0x7F, "\n") if $? & 0x7F;
        die("Child died with code ",   $? >> 8,   "\n") if $? >> 8;
        die("Unknown error waiting for child\n");
    }

    print("Child exited successfully\n");
}
[download]

* — Yeah, the documentation says $! will be zero in this instance, but I don't trust it. At least one other instance where the docs ignored "$! is only meaningful on error" has turned out to be wrong.

I don't know the mibtable program, but are you sure it works in a pipe? Is Illegal seek coming from perl or mibtable? I suggest you try the program with exactly the same parameters on the command-line piped to something like od(1). Maybe it is trying to do operations (like a seek) on the pipe which are illegal. An strace or truss might help as well.