John McKee wrote:
a tale of woe involving qp2shell, expect, sftp...
My observations:
It appears your only need of Expect in this scenario is to supply the ssh
password. The rest of the scenario could be accomplished with the batch
mode capability built into sftp. If your partner allows (and it would seem
strange that they would not since it means all of their clients will suffer
with the very same complexities and issues that you are) you could
authenticate with SSH Public Key Authentication and eliminate Expect from
your scenario. (If you want to learn more about Public Key Authentication,
Google "OpenSSH Public Key Authentication" to see lots of articles
describing this).
As Scott Klement mentions, if you are committed to doing this with Expect,
you'll need to put additional logic into your Expect script to detect the
sftp failure and surface that back to Expect's caller. Using sftp in batch
mode within Expect might make it easier to detect the sftp failure (by
checking sftp exit status in the Expect script) and then you just need to
get the Expect script to also return a non-zero exit status to it's caller.
I'm not certain that it is a problem, but it would make me nervous to start
all of this off with QP2SHELL. I believe you are doing exactly what Usage
Note 2 in the QP2SHELL documentation (
http://publib.boulder.ibm.com/infocenter/systems/scope/i5os/topic/apis/qp2shell.htm )
is trying to warn you not to do (i.e. you're running a shell script via
QP2SHELL). When QP2SHELL is used to start another shell (/usr/bin/sh in
your example) the stdin/stdout/stderr descriptors inherited by /usr/bin/sh
are the "plain" ILE descriptors from the job that called QP2SHELL. Those
ILE descriptors can act in strange ways when they are fork'd (or spawn'd)
into new child jobs as your shell script and Expect will be doing. Probably
better to start this off via QSH versus QP2SHELL.
midrange.com
