Ah, sorry -- I didn't quite catch what you'd meant.

You're saying that when you use a program that writes to STDERR, you are not additionally using the re-piping?

Okay.

So maybe there's a 32K limit on STDERRwhen run through $ssh->cmd-- and maybe that's tunable, still waiting on other Monks to respond on that point. But, an idea --

Maybe you can work around the limitation by piping only STDERRand piping it to its own file instead of capturing it on the $ssh->cmdcall, and then transfer the resulting file back:

my ($stdout, $stderr, $exit) = $ssh->cmd('/tmp/b 2>/tmp/b.err');
# Now read /tmp/b.err from remote system to get STDERR output.
# Don't forget to delete /tmp/b.err on the remote system when you're d
+one
[download]

If that doesn't work around the issue, or if it's not an option to write to the remote /tmpdirectory, I think I'm out.  :-(

Edit: Clarified remote file as being in /tmp and added note about remote file cleanup

Thank you and this is a good suggestion.

In debugging I have found that perl hangs in Net::SSH::Perl::SSH2 in the routine 'sub client_loop' in the line 'my($rready, $wready) = $select_class->select($rb, $wb);' but I do not have enough understanding to see why. I hope you or some kind monks can shed some light on this.

Also it is strange the same works with output to STDOUT.

I agree it is strange; but I will fall back on my first comment here:

• STDOUTis handled "normally" -- I'll go out on a limb here and characterize it as "system-level buffered stream I/O" and pray I didn't just embarrass myself (more than usual) with that line.  :-) Thus, it behaves normally.
• STDERR, on the other hand, seems to get "special" handling -- some kind of additional buffering beyond the standard "system-level buffered stream I/O". My guess is that herein, in this extra handling, that we've tripped on a landmine; and thus hoping that by piping it to a file, we circumvent the problem.

So...did it work?