search

lloydsparkes / mintty

Automatically exported from code.google.com/p/mintty
GNU General Public License v3.0
0 stars 0 forks source link

Improve support for native console programs #56

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Start the Win32 Python (not the Cygwin port) inside mintty

What is the expected output? What do you see instead?
The interactive Python prompt should be displayed. Instead, nothing happens
and the shell remains suspended until I press Ctrl-C.

What version of the product are you using? On what operating system?
0.3.5-1

Please provide any additional information below.
Win32 Python is works fine under Console2
(http://sourceforge.net/projects/console/), which is a different Windows
terminal emulator.

Original issue reported on code.google.com by sami.kyo...@gmail.com on 17 Feb 2009 at 3:07

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
@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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
> 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
The mintty+console workaround is definitely not usable.

Original comment by br.renatosilva on 10 May 2014 at 3:48

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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