Open GoogleCodeExporter opened 9 years ago
[deleted comment]
[deleted comment]
This issue sucks so much. It's a shame all the windows distributions of popular
tools are moving away from Cygwin to native. The experience is just terrible
outside of the cmd.exe terminal.
MSysGit is a perfect example. :(
Console2 feels laggy and has some bugs but it's the best I can find so far.
Original comment by jke...@gmail.com
on 14 May 2012 at 11:33
@jkells I feel your pain, but Cygwin's got a well-maintained git package, so
no, MSysGit doesn't seem a good example.
Original comment by andy.koppe
on 20 May 2012 at 2:04
Andy,
I wrote two separate wrappers for my terminal:
1) One wrapper creates CYGWIN TTY to run CYGWIN programs in my terminal (open
source wrapper).
2) Another wrapper creates hidden MS Console window and runs on it Windows
programs that cannot run without MS Windows console window attached. This
wrapper is closed source, but free to use (at least for now) and signed by my
developer certificate.
3) My terminal interfaces with the wrappers via their STDIN/STDOUT/STDERR UTF-8
byte-streams (plus some NAWS and Ctrl-C handling on STDIN).
Details on both wrappers are on my web-site on this page:
http://sergeybelous.com/shell-terminal/
Both wrappers are attached to my post and they are also installed as part of my
freeware application (http://sergeybelous.com/).
BTW, my software has workspace manager and its own built-in terminal and
command/script/plugin LauncherTree. And it also allows to run PuTTY and MinTTY
windows inside of my workspaces.
Thx,
Sergey
Original comment by belous...@yahoo.com
on 31 Oct 2012 at 3:20
Attachments:
[deleted comment]
[deleted comment]
Please fix this, it's a big annoyance not being able to use Python, Ruby, and
other programs from within MinTTY.
Original comment by br.renatosilva
on 21 Jan 2013 at 9:31
To use CYGWIN TTY terminal (like MinTTY) to work with programs that require MS
Windows Console Window (like PowerShell) one has to use special console
wrapper. Attached picture shows an example. To start wrapper with CMD instead
of the PowerShell use "proxywinconsole cmd" on command line.
Limitations of the wrapper:
1) terminal width is always 80 columns;
2) it is not possible to use command line editing keys (like backspace or
up-arrow).
I hope this will help,
Sergey
Original comment by belous...@yahoo.com
on 8 Mar 2013 at 12:37
Attachments:
In the related msysgit issue [1] someone has mentioned ConEmu [2] which
seemingly works fine with both Cygwin and native Windows console programs.
Maybe mintty could borrow some code from ConEmu to also make interactive
non-Cygwin programs work?
[1] http://code.google.com/p/msysgit/issues/detail?id=29#c49
[2] http://code.google.com/p/conemu-maximus5/
Original comment by sschuberth
on 19 Mar 2013 at 9:13
Why is the conin download marked as "deprecated" so that one doesn't even see
it by default on the download page? Is there a better way than conin? Where
does one obtain the source for conin?
Original comment by tripleQu...@gmail.com
on 20 Mar 2013 at 3:48
Re #60: ConEmu uses the same approach as Console2 of creating a hidden console
windows and displaying their screen buffers in its own window. Obviously this
means great support for native console programs, but it also means that it
relies on the Cygwin DLL's builtin console-based terminal emulation for Cygwin
programs, with the limitations that that entails, for example 16 colours, no
underline, slightly non-standard terminal emulation (hence the "cygwin"
terminal type).
ConEmu does have a special DLL-injecting hack for supporting colour control
escape sequences and 256 colours in console programs, but that doesn't work
with Cygwin programs.
As discussed at length above, there does not appear to be a way of seamlessly
combining the console wrapper approach with mintty's pseudo terminal device
approach. The next best thing is a wrapper utility such as ryan.prichard's
winpty (see #49), which has to be invoked explicitly for programs that need it
: https://github.com/rprichard/winpty. I'd love to hear about people's
experience with that.
Re #61: I never got around to "productising" conin. It's little more than
proof-of-concept, so I don't feel comfortable to offer it more prominently. Its
source is here: https://code.google.com/p/mintty/source/browse/utils/conin.c
Original comment by andy.koppe
on 20 Apr 2013 at 5:56
> Why is the conin download marked as "deprecated" so that one doesn't even see
it by
> default on the download page? Is there a better way than conin? Where does
one obtain
> the source for conin?
The tool is no longer being developed and has some unaddressed problems. In my
case, conin cannot be used to output ANSI colors. I use 'winpty' (mentioned
elsewhere in this thread) which seems to alleviate my issues.
Original comment by dvug...@gmail.com
on 10 Jun 2013 at 8:49
Following the previous comments in this thread, it seems that simply launching
bash via winpty allows all subsequently launched console apps to work inside
mintty! No need to lauch *every* individual app via winpty. Just a shortcut
like this does the trick:
mintty.exe -e console.exe bash.exe
mintty.exe - from msys
bash.exe - from msys
console.exe - winpty compiled from https://github.com/rprichard/winpty
I verified this by launching python.exe from inside bash with and without the
winpty wrapper. IMHO, I'd call this a closed issue, because with such a simple
solution there's no need for mintty to auto-launch winpty. Maybe this should
be added to the tips wiki page?
Original comment by jonatha...@gmail.com
on 15 Jun 2013 at 8:30
[deleted comment]
[deleted comment]
I can confirm the solution of Jonathan, but it has some minor issues.
1. There is some latency (may or may not be noticable to the user).
Here are some quick timing test from my system. Command is:
time for i in {1..100000}; do echo test; done
Mintty started via mintty /bin/bash --login -i:
real 0m2.516s
user 0m2.247s
sys 0m0.141s
Mintty started via mintty /usr/local/bin/console /bin/bash --login -i:
real 0m13.290s
user 0m3.541s
sys 0m3.448s
2. Colors get messed up. I use customized colors on my cmd windows. Mintty also
uses the same color (different from the mintty/bash settings) if started via
winpty. You may look at the screenshot for example. Left is normally started
bash, middle is bash started via console.exe and the right side is cmd.exe
Original comment by mertdi...@gmail.com
on 19 Jun 2013 at 9:00
Attachments:
forgot to add, it's on Cygwin 1.7, winpty is compiled using Cygwin's mingw
tools.
Original comment by mertdi...@gmail.com
on 19 Jun 2013 at 9:01
Since using it for a few days, there's also some weird behavior with keyboard
handling. Particularly, launching vim inside an ssh session inside bash inside
console.exe seems to not be particularly happy. :) Not too big of a deal,
cause I can just launch ssh from a clean mintty anyway.
Jonathan
Original comment by jonatha...@gmail.com
on 20 Jun 2013 at 9:45
This is actually a big problem now that cygwin defaults to mintty.
It really isn't a solution to say that windows console programs can't be run
from cygwin terminals.
We have a diagnostic program that is built as a windows console program - so
that it can be run on systems without cygwin. It is also built for Linux, there
are very few differences in the code.
The windows program used to use _kbhit() and _getch() to do non-blocking
console input, and expects ^C to actually cause the SetConsoleCtrlHandler()
function to be called.
Since _kbhit() and _getch() don't work, I've created a thread that uses _read()
and puts the data into a ring buffer (I can live with the input consequences).
However that version of the program blocks inside LoadLibrary() after the
library file has been opened (on XP at least) - so i can't use it. The library
doesn't have an init function, and I've NFI how to find out where it blocks.
If I type ^C on either version the program goes 'not responding' for about 10
seconds and then exits - again I've NFI about where to look to find out what it
is doing.
These might be mintty issues, and they might be cygwin ones - but they are real
problems.
FWIW I have the programming skills to fix this - assuming it is possible, but
not the knowledge of the current architecture (or windows internals).
Original comment by david.la...@aculab.com
on 27 Jun 2013 at 10:33
comments #64 and #67 do work quite well. Git becomes usable from Mintty with
colors and default paging working correctly. About the only significant issue
I have is that "less" (both when invoked automatically by git and when invoked
manually) doesn't use arrow keys etc - only "jkbf" etc work for navigation.
Another minor problem is that the title of the window doesn't change with the
pwd. But all things considered, things are definitely improved.
Original comment by skippy.hammond@gmail.com
on 7 Aug 2013 at 1:48
FTR, in addition to what I mentioned in comment #71, there are numerous other
issues. Editing multi-line commands in the shell does strange things,
multi-line "copy" from the console only grabs the first line, type-ahead no
longer works (ie, any characters typed while a command is executing are lost)
and a few other issues which I've forgotten. I've since moved back to setting
up a bash function so console.exe is only used when executing git.
Original comment by skippy.hammond@gmail.com
on 20 Aug 2013 at 7:15
I spent a long time trying to figure out why my reads were always getting
line-buffered under mintty for my native windows application. I finally found
that Cygwin does some crazy shared-memory tricks to expose tcsetattr to the
client for cygwin (or msys) programs, so that flags like ICANON in the client
get written into the server's memory. Since the server is providing the
implementation of these flags, it is hard for a non-cygwin program to control
them.
Therefore, for native windows applications, it seems that it would greatly help
compatibility if mintty could provide some built-in `stty`-like functionality
(or perhaps always ship with the Cygwin stty program) to allow the client
program to (be programmed to) control the ICANON, ICRNL, IECHO, and other flags.
Original comment by vtjn...@gmail.com
on 23 Mar 2014 at 1:39
[deleted comment]
[deleted comment]
The mintty+console workaround is definitely not usable.
Original comment by br.renatosilva
on 10 May 2014 at 3:48
Re: A request for showing the current working directory in title when using
winpty.
Using winpty as outlined in q#64 seems to work very well. Thank you Ryan
Prichard!
mintty.exe -e console.exe bash.exe
I'm using it for python and mysql among other Windows console-based programs.
That being said, there are issues with colors and arrow keys, neither of which
are too important to me.
@Renato -- a few words about what else you've found that doesn't work would be
helpful.
I spent a little time with mintty in GDB looking at what mintty is getting from
console/winpty. It seems that the title-change escape sequence in my bash
prompt is stripped out and new escape sequences are inserted. Since this is
happening before mintty even sees it, unless winpty can be made smarter, or a
different way of passing back the CWD to mintty can be found, I don't see a
sensible way to do it.
Original comment by eric.wou...@gmail.com
on 10 May 2014 at 10:25
[deleted comment]
[deleted comment]
Git for Windows has some code that modifies the internal file handles such that
native isatty() functions return true. This may be useful for mintty in
helping deal with this issue:
https://github.com/git-for-windows/git/blob/master/compat/winansi.c#L465-L533
Original comment by elysc...@gmail.com
on 7 Apr 2015 at 8:04
Original issue reported on code.google.com by
sami.kyo...@gmail.com
on 17 Feb 2009 at 3:07