It actually took a little digging to find out how to properly handle the output and the various return codes of qx when executing an ssh command.

Why would you actually want to do such a thing to begin with? You wouldn't. Don't do it. Stop! For the love of ...

If, however, you have a machine who's operating system hasn't had a vendor supported upgrade any time this century, you may not have a choice.

I feel your pain. It runs deep, share it with me.

sub ops_do_ssh_qx { my ($cmd) = @_; $cmd->{ssh_cmd_qx} = 'ssh ' . $cmd->{user} . '\@' . $cmd->{host} . + ' \'' . $cmd->{command} . '\'' . ' 2>/dev/null'; $cmd->{output} = qx($cmd->{ssh_cmd_qx}); if ( defined $cmd->{output} ) { $cmd->{cmd_ret_code} = $?; chomp $cmd->{output}; if ( $cmd->{cmd_ret_code} ) { $cmd->{success} = FAILURE; } } else { ($cmd->{ssh_ret_code}, $cmd->{ssh_ret_msg}) = (0 + $!, '' . $!); $cmd->{success} = FAILURE; } return $cmd; }

The hash you pass in looks like this:

my $cmd = { name => 'foo', user => 'foo_user', host => '', command => 'do_something_useful_here', success => SUCCESS };

And you invoke it thusly:

my $cmd_status = ops_do_ssh_qx($cmd); if ( $cmd_status->{success} ) { do_something_with $cmd_status->{output}; } else { do_something_with $cmd_status->{cmd_ret_code}, $cmd_status->{ssh_re +t_code}, $cmd_status->{ssh_ret_msg}; }

Unfortunately the values you end up with in

$cmd_status->{cmd_ret_code} $cmd_status->{ssh_ret_code} $cmd_status->{ssh_ret_msg}
are, for both the OS and SSH, implementation dependent, which is just one of the reasons you shouldn't be doing this if you have a choice.

If anybody finds this useful, you have my condolences.


Update: haukex has a great write up regarding alternatives to qx/backticks here Calling External Commands More Safely. My Perl was too old for the ones I tried, but afoken has indicated that piped opens are available even in 5.004.