40

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), 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?

James Kanze
  • 150,581
  • 18
  • 184
  • 329
  • Very similar: [windows - Python not working in the command line of git bash - Stack Overflow](https://stackoverflow.com/questions/32597209/python-not-working-in-the-command-line-of-git-bash?newreg=2b3bd8a46fe54124b460460afe98180f) – user202729 Aug 16 '21 at 13:50

8 Answers8

56

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
nngeek
  • 1,912
  • 16
  • 24
vikkyhacks
  • 3,190
  • 9
  • 32
  • 47
  • this works perfectly. It would be better to add some information on `python -i` option in the answer so that others no need to do a `python -h` to figure it out. – nngeek Mar 27 '20 at 01:15
43

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.

Adam Rosenfield
  • 390,455
  • 97
  • 512
  • 589
  • 2
    +1 - switching from Windows Python27 to Cygwin Python32 solved this issue I had as well. – mouviciel Nov 27 '12 at 16:56
  • 5
    Thanks. I can't change the version of Python (without installing 2 versions, one for CygWin, one for everything else), because it is part of our production build chain. But `python -i` works, and creating an alias in `.bashrc` is probably an acceptable solution. – James Kanze Nov 27 '12 at 17:01
  • 4
    [This answer](http://stackoverflow.com/a/9549255/9530) also gives some more suggestions of which I was previously unaware -- running Python with the `-u` command line switch or setting the environment variable `PYTHONUNBUFFERED=1` will change Python's buffering behavior. – Adam Rosenfield Nov 29 '12 at 16:51
  • But if you've been locked down and can't install or build the following alias may potentially work for you: `alias python='winpty python.exe'`: https://github.com/git-for-windows/git-sdk-64/pull/35 – NeilG Nov 25 '22 at 00:44
11

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.

martian111
  • 595
  • 1
  • 6
  • 21
  • 2
    I *finally* got the 50 reputation points to say THANK YOU!. While the '-i' works in most cases, we have lab software that runs mostly cygwin, but then calls out to a windows python since it needs ctypes.WinDLL. This win call has an embedded ipython prompt and that was royally messed up on mintty (tabs/arrows didn't work, were all goofy). This is the easiest and best solution -- worked like a charm. In bash script, just did "console.exe C:\Python27\python.exe" and now the embed ipython works great! Was pulling hair out, cause on 64 bit windows, mintty is only terminal game in town. – Andrew Carter Mar 03 '15 at 15:29
  • Not sure how `python -i` actually manages to change the terminal buffering and read individual characters. It must be doing something clever under the hood. Either way `winpty` was the way to go with my Python _script_ which wasn't so clever. – Graeme May 15 '19 at 15:32
  • Should add that the executable name for `winpty` has now been changed from `console.exe` to `winpty.exe`. – Graeme May 15 '19 at 15:34
3

another universal workaround is invoking it via winpty https://github.com/rprichard/winpty and this is not really a python specific issue.

Ben
  • 1,133
  • 1
  • 15
  • 30
2

According to https://stackoverflow.com/a/9549255/745913 you can also try

/cydrive/c/Python27/python.exe -i foo.py
Community
  • 1
  • 1
seeker
  • 1,136
  • 1
  • 13
  • 16
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.

Ross Hodapp
  • 11
  • 1
0

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.

Juraj
  • 1,120
  • 9
  • 10
-1

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

Mr. hrfister
  • 1
  • 1