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:Python27python), and added both the CygWin bin and the
Python directory to my path (in the user variable PATH). From
the normal command window, Python starts up perfectly, but when
I invoke it from bash in the CygWin environment, it hangs,
never giving my the input prompt.
I’ve done this on other machines, previously, but always with
older versions of Python (32 bits) and CygWin, and with Python
in a decidely non-standard location. Has anyone else had this
problem, or could someone tell me what it might be due to?
Answers:
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.
According to https://stackoverflow.com/a/9549255/745913 you can also try
/cydrive/c/Python27/python.exe -i foo.py
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
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.
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.
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.
another universal workaround is invoking it via winpty https://github.com/rprichard/winpty and this is not really a python specific issue.
Reinstall mintty with cygwin setup. Didn’t have to use python -i after that.
Installing a new Windows system, I’ve installed CygWin and 64
bit Python (2.7.3) in their default locations (c:cygwin and
c:Python27python), and added both the CygWin bin and the
Python directory to my path (in the user variable PATH). From
the normal command window, Python starts up perfectly, but when
I invoke it from bash in the CygWin environment, it hangs,
never giving my the input prompt.
I’ve done this on other machines, previously, but always with
older versions of Python (32 bits) and CygWin, and with Python
in a decidely non-standard location. Has anyone else had this
problem, or could someone tell me what it might be due to?
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.
According to https://stackoverflow.com/a/9549255/745913 you can also try
/cydrive/c/Python27/python.exe -i foo.py
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
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.
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.
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.
another universal workaround is invoking it via winpty https://github.com/rprichard/winpty and this is not really a python specific issue.
Reinstall mintty with cygwin setup. Didn’t have to use python -i after that.