"Jim Carroll" <jim@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