In article <[EMAIL PROTECTED]>, Martin Franklin <[EMAIL PROTECTED]> wrote:
> Skip Montanaro wrote: > > I have an os.spawnv call that's failing: > > > > pid = os.spawnv(os.P_NOWAIT, "ssh", > > ["ssh", remote, > > "PATH=%(path)s nice -20 make -C %(pwd)s" % locals()]) > > > > When I wait for it the status returned is 32512, indicating an exit status > > of 127. Unfortunately, I see no way to collect stdout or stderr from the > > spawned process, so I can't tell what's going wrong. > > > > The "ssh remotehost PATH=$PATH nice -20 make ..." command works fine from a > > similar shell script. ... > While not a 'real' answer - I use pexpect to automate my ssh scripts > these days as I had a few problems using ssh with the os.* family > perhaps you may find pexpect a wee bit easier... Also, a "-n" can also improve reliability. By default, ssh assumes that you meant to copy data as input to the remote command, and it does so if it can. Very likely at the expense of some other process that you expected would be able to read that data later. -n informs ssh that you don't intend to provide any data to the remote command. But that's probably not the present problem. (Not that it's really all that "present" by now!) 127 seems to mean that the "ssh" command couldn't be found or couldn't be executed. I guess if something like that were really getting me down, I might rewrite os._spawnvef with a pipe. On entering the except clause I'd format the exception and write it to the pipe; otherwise, I'd just close the pipe. The parent could then read the pipe, even for a NOWAIT case like this, and possibly contrive to re-raise the fork's exception if one showed up. This would account for the class of errors that occurs between the fork and the exec. The _spawnvef I'm looking at doesn't account for these very well - 127 covers a lot of ground, and there wouldn't be much in the way of error output. Donn Cave, [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
