Invoking python under CygWin on Windows hangs

Question

Installing a new Windows system, I\'ve installed CygWin and 64 bit Python (2.7.3) in their default locations (c:\\cygwin and c:\\Python27\\python),

Answer 1

For managing non-cygwin locations of different versions of Python in CygWin:

$ /usr/sbin/alternatives.exe

Use the --install and --config options here, it works the same as update-alternatives on a Linux system. I'm using this along with the python -i approach, and it's working well.

I also had to delete the sym-link files in /usr/binfirst, since they were installed with CygWin's python and not managed via alternatives.exe initially.

Answer 2

I had a similar issue with Mercurial (hg)+OpenSSH, Python and MinTTY, but under MSYS instead of CygWin. Nonetheless, as far as I can tell, both this and my issue were caused by MinTTY not being to handle applications that uses the native Windows console functions (in an answer here by Adam, he explained it in detail for Python).

For me, I followed the solution found in comment 64 of https://code.google.com/p/mintty/issues/detail?id=56#c64

With the winpty (https://github.com/rprichard/winpty) project compiled and in my path, I was able to run native Python (in interactive mode) and Mercurial from the MinTTY shell without special builds or switches (such as python -i). All I need was to append console.exe or console before the python or hg command. For convenience, I added aliases such as alias hg="console.exe hg" so I can use the same commands whether I'm in a Linux shell or a Windows MinTTY bash shell.

Also, this solution seems to work for more native applications beyond python and hg. For example, running mysql (with or without -p) would have given the same problem (e.g. "hangs" with no input prompt). Appending console to it allowed it to as usual.

Answer 3

Reinstall mintty with cygwin setup. Didn't have to use python -i after that.

Answer 4

The problem is that due to the way that the Cygwin terminal (MinTTY) behaves, the native Windows build of Python doesn't realize that stdout is a terminal device -- it thinks it's a pipe, so it runs in non-interactive mode instead of interactive mode, and it fully buffers its output instead of line-buffering it.

The reason that this is new is likely because in your previous Cygwin installation, you didn't have MinTTY, and the terminal used was just the standard Windows terminal.

In order to fix this, you either need to run Python from a regular Windows terminal (Cmd.exe), or install the Cygwin version of Python instead of a native Windows build of Python. The Cygwin version (installable as a package via Cygwin's setup.exe) understands Cygwin terminals and acts appropriately when run through MinTTY.

If the particular version of Python you want is not available as a Cygwin package, then you can also download the source code of Python and build it yourself under Cygwin. You'll need a Cygwin compiler toolchain if you don't already have one (GCC), but then I believe it should compile with a standard ./configure && make && make install command.

Answer 5

Try this

python -i

and yes you will find some glitches here and there !!!

Option -i forces an interactive prompt as shown in Python help python -h page here.

$ python -h
-i  : inspect interactively after running script; 
      forces a prompt even if stdin does not appear to be a terminal;
      also PYTHONINSPECT=x

Answer 6

My solution involved writing a shell script to run the python app.

python file.py "$@" | tee /dev/null

That extra tee command (to nowhere) seems to fix the issue.