[Twisted-Python] Stdout from child of ProcessProtocol not propogating

[David Bolen]

"Jim Carroll" <jim at carroll.com> writes:

> After you get the CMD.exe prompt, try to launch python.  This is what you'll
>
> see:
>
>  
>
>     Microsoft Windows [Version 6.3.9600]
>
>     (c) 2013 Microsoft Corporation. All rights reserved.
>
>  
>
>     C:\Temp>python
>
>     python
>
>  
>
>  
>
> That's it. Hitting enter just drops down to another next blank line. 

I suspect it's not a Twisted issue as much as a common risk running
programs in a child process under Windows, especially executables using
the standard C RTL with its default stdout buffering behavior.

Do the built-in commands like DIR work ok?  If so, then it's likely that
it isn't that stdout isn't making it back to the client; rather it isn't
even making it to your parent Twisted process.  Usually it's a buffering
or tty detection issue since a Windows child shell won't appear to be a
tty.  I'll note that python behaves the same way you describe when run
from within a cmd shell under Cygwin's ssh server for example.

In python's case, the C RTL is going into fully buffered mode.  You
should eventually get output once enough is generated (~8K) or the
process exits.  You can't control how the child executable will buffer
from the parent unless the executable provides a way.  So how you work
around the issue depends on the actual command being run.

Assuming this is the issue you're running into, using either "python -u"
(if you just need output as it occurs) or "python -i" (for interactive
use) should be a workaround.  Or if you want to avoid clients having to
remember the options, you can install appropriate environment variables
(PYTHONUNBUFFERED or PYTHONINSPECT respectively) into the child process.
But that's Python specific - there's no general solution for all
executables, and there will be some for which you simply can't disable
the buffering.

The other thing you have to watch out for are executables you may run
that actually use the Win32 console API rather than interact with
stdin/stdout.  Or certain methods of character inputs (like Python's
msvcrt.getch).  Again, not a Twisted issue, but you can't interact with
that (unless you jump through some significant hoops).  This shows up
often with password prompts (which want to prevent echoing), curses like
applications, or even in unexpected places for Y/N prompts in some
utilities (like SC's default help, or NET TIME /SET's confirmation).

Of course if you're just implementing the ssh server portion, you should
be able to pretty much punt on it and leave it up to the user to
determine how to best run whatever commands they are using.  The
behavior with your shell should be similar to other remote shell
approaches.

-- David