This is the mail archive of the
mailing list for the Cygwin project.
Re: mintty/Windows interoperability (was: Re: default terminal)
On 3 June 2010 21:25, 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.
> 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?
Can't be done in mintty, because it doesn't have a handle on the
invisible console created by the call to exec() in the forked child
process. As discussed below, this could be done in the DLL though.
>> 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.
Yep, I checked that chcp sets both the input and output codepages. And
compared to the pipe idea, this one is relatively simple and doesn't
have significant overhead (although of course it fails more often).
>> 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.
>> 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.
But only to the codepage vs charset issue, not to the wider and more
serious issue that console operations fail on a pipe handle. Even
ignoring that, I can already think of two ways for the idea to fail:
- The Windows process might change the console codepage (repeatedly),
which means the stub process would need to use GetConsoleCP and
GetConsoleOutputCP on every I/O operation to try and keep up. That'd
further add to the overhead, but since there's no synchronisation,
you'd still get stuff being translated with the wrong codepage.
- With console handles you can use WriteConsoleW to directly write
Unicode (i.e. UTF-16) output. That of course doesn't work on pipes or
files, nor is there a WriteFileW that does support Unicode output on
them. What you get is WriteFile, which deals in bytes. Hence an
application might do something like the following to get both console
output and output that's redirected to a file working:
The trouble there is the hardcoded CP_OEMCP, which assumes that the
console codepage is set to the default (e.g. CP850 on Western European
systems), so if it's set to something else, bang.
Here's an article that recommends just such an approach, except it
hardcodes CP_ACP, which doesn't even match the default console
Application bug? Arguably, but it worked in the console ...
>> 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.
You're scaring me now. :(