This is the mail archive of the
mailing list for the Cygwin project.
Re: mintty/Windows interoperability (was: Re: default terminal)
- From: Thomas Wolff <towo at towo dot net>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 03 Jun 2010 22:25:48 +0200
- Subject: Re: mintty/Windows interoperability (was: Re: default terminal)
- References: <AANLkTimLbuz7V2yTfJrd1e9n3d9lEZ6crMsl2v85oguM@mail.gmail.com> <20100531212927.GI18315@ednor.casa.cgf.cx> <4C0442DA.email@example.com> <4C06C175.firstname.lastname@example.org> <AANLkTim4Nv4e9QSUgFeF6TLg-vcStqMI9SDclcwLJqiL@mail.gmail.com>
Am 03.06.2010 20:17, schrieb Andy Koppe:
On 2 June 2010 21:39, Thomas Wolff wrote:Ah, right! I had not noticed this, only that error message are not
fixed. Something else that *is* fixed this way is e.g.
* Another issue with even those Windows/DOS programs that do work inUnfortunately the common (i.e. cheaper) variants don't allow you to
general: They assume the Windows ANSI encoding so their output
(and input assumption) will not match the mintty character
encoding in most cases. (Test case: configure Windows UI to
"German", reboot (grumble)
change the UI language.
run mintty in UTF-8, enter 'xcopy'Ah, 'chcp' actually is a cmd.exe builtin, so you need to run it like
(without parameters), see error message "Unzulâssige
Parameteranzahl"). This works fine in the Cygwin Console because
the I/O method used by those programs bypasses cygwin - the Cygwin
Console is actually a dual-character set environment. My initial
idea that Windows could be convinced to change that for mintty
with 'chcp.com 65001' failed.
this: 'cmd /c chcp 65001'. I can't test the xcopy error message, but
this did at least yield correct umlauts in filenames when doing a 'cmd
cmd /c help
(which also shows that cmd has a built-in chcp in addition to the
stand-alone chcp.com that at least Windows XP has).
So this would be a partial work-around, and maybe an easy one if mintty
just aligns the chcp setting with the locale automatically?
When a Windows process is invoked from a Cygwin process using exec()
or spawn(P_OVERLAY, ...), the Cygwin process "hangs around as a 'stub'
pid as the win32 process's pid, to allow cygwin tools to kill the
win32 process." (From winsup/cygwin/how-spawn-works.txt.)
My thinking was that using a couple of extra pipes, that process could
in theory translate between the console's codepage and the locale
charset. The place to hook that in would be spawn_guts() in
winsup/cygwin/spawn.cc. That function is a scary place though, and
I've got no idea whether such an approach could work.
This sounds as if it would have the same effect as chcp, so it might be
worth a try.
The best thing to do then would be to wrap the spawnedThere might be another possibility: when the invisible console is
Windows/DOS program into something like 'luit'. A work-around
would also be to switch mintty encoding dynamically but that would
not work with multiple programs producing output simultaneously,
for example from a background process.
created in fhandler_console::need_invisible, set its input and output
codepages according to the locale charset (using SetConsoleCP and
SetConsoleOutputCP). Obviously that could only work for locale
charsets that do have an equivalent Windows codepage, or at least
something close (like CP1252 vis-a-vis ISO-8859-1).
In the end though, these ideas are all imperfect workarounds.
It seems to me the idea with the hook you outlined above would be a
solution, not just a workaround.
Given that there is a straightforward answer to any issue with consoleMaybe. Or, maybe, as cgf said:
programs ("use a console"), I find it hard to justify much effort
going into them.
There is no way to know though. It could be that there is an applicationImagine thousands of complaints after making mintty the default...
That's something mintty would not deserve, so avoiding it might be a
used by thousands that works well in the console window while failing
miserably under a tty/pty.