Re: Odd perl/ssh interaction

Maybe you could store the output of the hosts command into an array and then loop over the array to issue your ssh instruction.

Also, rather than storing the output of the ssh command into a file, it might be simpler to issue the command with backticks and store the result into a variable. Something like this (untested):

my $uptime_output = `ssh $_ 'uptime'`;
[download]

(I don't know whether you need redirection in the ssh command. I would assume the output should come on STDOUT.)

Comment on Re: Odd perl/ssh interaction Select or Download Code

Replies are listed 'Best First'.
Re^2: Odd perl/ssh interaction by afoken (Chancellor) on Jul 08, 2017 at 15:19 UTC
Backticks, like two-argument pipe opens, share the same problem: Undefined default shell behaviour. See Re: Ssh and qx. Using a perl SSH agent would entirely avoid the subprocess and the default shell. For a cross-platform, core-only solution, "Safe pipe opens" in perlipc explains how to avoid the default shell. The main trick in this case is to open `STDIN` from `/dev/null` in the child, then use multi-argument exec to prevent any interaction with the default shell. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]
Re^2: Odd perl/ssh interaction by mlf (Initiate) on Jul 08, 2017 at 13:29 UTC
Yes, reading the full host list is a valid work-around. Unfortunately though, backticks exhibit the same issue with STDIN being consumed by the ssh command. Ultimately adding -n to keep it from sucking up STDIN is the solution. Regarding the redirection in the shh command, normally your assumption would hold true as in the 'uptime' test case, but alas, the third party program I'm dealing with on the remote systems in the real use case was not written with proper *nix philosophy in mind and writes most of it's "output" on STDERR.	[reply]