4

I have installed Python with the Windows binaries, so I need to type python -i to start Python in Cygwin. And when I exit it I need to write exit(). It is just a minor issue, but I still would like to know if it possible to fix it so I can exit using Ctrl+Z like I do when I run Python in cmd

2
  • Try using Ctrl-D to exit instead.
    – MattDMo
    Mar 29, 2013 at 1:05
  • Already tried it, and it does not work either
    – starcorn
    Mar 29, 2013 at 1:43

2 Answers 2

2

To run Windows Python from within Cygwin, always do this:

$ cygstart python

Never do this:

$ python -i

This extends to Windows IPython as well. Always do this:

$ cygstart ipython

Never do this:

$ ipython -i

Before we get to why, however, let's talk ${PATH}.

Python and ${Path}: Together at Last!

The above answer assumes the python in your current ${PATH} to be the native Windows rather than Cygwin-installed version of Python. If the latter is the case, the absolute path of your Windows Python must be explicitly passed to cygstart. For example:

$ cygstart /cygdrive/c/Miniconda3/python.exe

If you run Windows Python with any semblance of frequency, you probably want to make that your definitive python. If you installed a popular Python distribution (e.g., Anaconda, Miniconda, Enthought Canopy), this means you. To do so, prepend ${PATH} by the absolute path of the directory containing python.exe on shell startup (e.g., in ~/.bashrc). For example:

# Stash this somewhere.
export PATH="/cygdrive/c/Miniconda3:${PATH}"

What's Wrong with python -i or cmd.exe, Chummer?

On espying yet another well-intended recommendation to run Windows Python via either python -i from within Cygwin or python from within a non-Cygwin terminal, I only shake the head.

No. No. No. In both cases, you're doing it wrong.

In the case of running python -i from within Cygwin, you lose sane keyboard bindings (e.g., <Up> and <Down> to cycle through the REPL history, <Ctrl-D> to terminate the REPL) and, perhaps more importantly, output buffering.

In the case of running python from within a non-Cygwin terminal, you lose Cygwin. You use Cygwin for a reason – presumably because you prefer POSIX-compatibility and everything that entails (e.g., a sane shell) to the conventional Windows alternative.

What's So Smoking Hot about cygstart, Anyway?

There's no reason to drop Cygwin. There's every reason, however, to run a native Windows application and hence Windows Python from within Cygwin as a native Windows process rather than as a POSIX-compatible Cygwin process. Which it's not.

Enter cygstart.

This standard Cygwin utility is (rather confusingly) overloaded to interface in a variety of marginally interesting ways with native Windows applications, paths, and URIs. For our purpose, passing cygstart the name of a command in the current ${PATH} runs that command as a native Windows process, preserving Windows shell syntax and semantics in the presence of Cygwin.

tl;dr

Native Windows applications – including Windows Python and IPython – should always be run from within Cygwin via the cygstart command.

1

The problem here is the difference between Cygwin terminal emulators (MinTTY etc), which try to act like Linux terminals for the benefit of native Cygwin apps, and the Windows cmd terminal emulator. Because MinTTY handles signals differently, it won't pass Ctrl+Z as an EOF signal to Windows Python, while Ctrl+D isn't handled by Windows Python at all.

The solution is to stick to using Windows Python in Windows terminal emulators (ie the cmd terminal emulator, which is the same one as you get if you start Windows Python from the Start Menu or similar), and to install Cygwin Python and use that from Cygwin terminal emulators. That way each will receive and handle the relevant signals correctly.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .