mintty/Windows interoperability (was: Re: default terminal)
Thu Jun 3 20:26:00 GMT 2010
Am 03.06.2010 20:17, schrieb Andy Koppe:
> On 2 June 2010 21:39, Thomas Wolff wrote:
>> * Another issue with even those Windows/DOS programs that do work in
>> 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)
> Unfortunately the common (i.e. cheaper) variants don't allow you to
> change the UI language.
>> run mintty in UTF-8, enter 'xcopy'
>> (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.
> Ah, 'chcp' actually is a cmd.exe builtin, so you need to run it like
> 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
> /c dir'.
Ah, right! I had not noticed this, only that error message are not
fixed. Something else that *is* fixed this way is e.g.
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'
> presenting it's
> 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.
>> The best thing to do then would be to wrap the spawned
>> 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.
> There might be another possibility: when the invisible console is
> 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).
This sounds as if it would have the same effect as chcp, so it might be
worth a try.
> 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 console
> programs ("use a console"), I find it hard to justify much effort
> going into them.
Maybe. Or, maybe, as cgf said:
> There is no way to know though. It could be that there is an application
> used by thousands that works well in the console window while failing
> miserably under a tty/pty.
Imagine thousands of complaints after making mintty the default...
That's something mintty would not deserve, so avoiding it might be a
More information about the Cygwin-apps