Your answer still leaves me believing you're not getting my point.

• Yes, the program writes to STDERR.
• Yes, you cannot control this.
• We suspect STDERRhas special handling issues.
• You are messing with STDERRwhen you re-pipe it using 1>&2.
• Messing with it might be the source of the hang.

Thus, I'm hoping that removing the 1>&2from your script might prevent the hanging under all cases.

But it might not. Won't know until you try it against all known cases that currently cause it to hang.

Thank you again for your help. Points 1-3 are correct but 3-4 are not. The original program writes the data to STDERR and hangs. I have demonstrated the behavior using the script above for simplicity - but in fact the behavior is the same using a program which writes to STDERR and the above example which uses redirection to write to STDERR.

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