Stderr handling in SSH Transport can yield wrong results

[kadler]

@jkyeung reported this on Ryvver when itoolkit-utils is not installed. Here's the relevant trace:

***********************
control Fri Aug 26 12:06:16 2022
 ipc(*na) ctl(*here *cdata)
input Fri Aug 26 12:06:16 2022
<?xml version='1.0'?>
<xmlservice><cmd exec="cmd" error="fast" var="cmd"><![CDATA[sndmsg tousr(jyeung) msg('Hello')]]></cmd></xmlservice>

output Fri Aug 26 12:06:16 2022
b'ry\n'
parse (fail) Fri Aug 26 12:06:16 2022
parse step: 3 (1-ok, 2-*BADPARSE, 3-*NOPARSE)

When I print out xml_out we get from the transport, I get a longer string:

b'tory in the path name does not exist.\n'

This is because our handling of reading stdout/stderr is not correct here: https://github.com/IBM/python-itoolkit/blob/main/src/itoolkit/transport/ssh.py#L97-L102

In this case, stdout contains no data. The first iteration of the loop we read the first 64 bytes from stderr, then read from stdout. Since stdout is empty, we close it. Next iteration, we read the next 64 bytes from stderr. Since stdout is closed, we skip reading it, but this leaves newData still set to the stderr data, so this gets assigned to stdout as well.

Dumping out stderr gives a much more sensible output:

b'bash: line 1: /QOpenSys/pkgs/bin/xmlservice-cli: A file or directory in the path name does not exist.\n'