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

[Thomas Wolff]

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