up vote 0 down vote favorite
share [g+] share [fb]

For compatibility with other Windows programs, I have to install the Windows version of Mercurial (vs. the Cygwin version), for Python, etc.

Unfortunately, these native Windows programs seem to have problems with interactive input in Cygwin shells. Furthermore, some native programs don't even run (msysgit makes me type "git.cmd" every time instead of "git").

I don't want to have to switch between two terminals all the time. What is the best workaround or compromise to this problem?

I've tried setting CYGWIN=notty as an environment variable but that doesn't seem to help either.

Thanks.

link|improve this question
feedback

1 Answer

up vote 1 down vote accepted

You'll need to use a Cygwin console (based on the standard Windows console) instead of the default Cygwin terminal.

One way to do that is to create a shortcut that directly invokes bash as a login shell, in which case Windows automatically creates a console window for it. Here's a command to create such a shortcut on the desktop:

mkshortcut -D -n "Cygwin Console" -i /Cygwin.ico /bin/bash -a --login
link|improve this answer
That's the same shell I've been using that's having problems with some Windows applications, though. :( – Jonathan Chan Dec 7 '11 at 0:26
You need to distinguish between the terminal/console, which is the thing displaying a text window, and the shell, which is the thing running inside that window and interpreting commands. Anyway, if you're already using the console, I'm a bit stumped. Are you running screen inside it? Is CYGWIN set to tty before the initial Cygwin process is started? Setting it to notty inside a Cygwin session won't make a difference. – ak2 Dec 7 '11 at 8:28
Sorry about that ambiguity, I meant terminal. No, I'm not running screen inside of it. I set CYGWIN to tty outside of the Cygwin session, of course. – Jonathan Chan Dec 9 '11 at 23:26
Then that's the problem. Setting CYGWIN to tty enables Cygwin's "pseudo terminal device" layer in the console, which gives you more Unix-compatible terminal funcionality (e.g. the ability to suspend processes with ^Z). However, this is based on Windows pipes, and means that native Windows programs get a pipe handle where they expect a console handle, and interactive programs often don't function as expected with those. – ak2 Dec 10 '11 at 10:12
"native Windows programs get a pipe handle where they expect a console handle, and interactive programs often don't function as expected with those." I think that that was the original problem. :P Thanks anyways! – Jonathan Chan Dec 10 '11 at 21:58
show 2 more comments
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.