This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mintty/Windows interoperability (was: Re: default terminal)


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 benefit.

------
Thomas


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]