Mail Archives: cygwin/2009/04/03/05:37:32
[For some reason I'm not receiving the mailing list right now once again,
so I hand-crafted the References and In-Reply-To headers of this mail,
if that matter.]
I had written:
> Now with 1.7.0-45, after remote login, the encoding is always just
> ISO-8859-1, while of course, if I have a UTF-8 terminal, I want to take
> this over to the remote system. Maybe it's some interworking problem
> with the new cygwin dll and the old rlogin.exe?
> Until 1.7.0-44, even something like the following worked:
> Inside a default cygwin console (or a codepage:oem) console, you could type
> CYGWIN=codepage:utf8 rlogin ...
> and get a UTF-8 remote terminal environment. Now, no attempt to
> establish that seems to work anymore.
Corinna wrote:
> These are the choices we have, afaics:
>
> 1. Use a "CYGWIN=codepage:foo" look-alike which only sets the console
> charset.
> ...
I can't imagine this would be necessary.
> 2. Use the environment variable setting of LC_ALL/LC_CTYPE/LANG at
> the moment the console is opened the first time and then never
> change this setting again until the console is closed again.
This would be normal as compared to other terminal applications.
I was actually surprised when I discovered that encoding can be
changed per application (kind of like with luit...), and I wonder
how this all works... On the other hand, maybe it's a useful feature
occasionally.
> Pro: Only one environment variable has to be set for the
> internationalization (which was the intent of the original patch).
This should be achieved, and I see no reason why a different setting
should be needed for the console window than for xterm or applications;
after all, this is just the variable that indicates what to do, the
problem must lie somewhere in the mechanism to interpret this information.
> Con: The variable must be set before starting a Cygwin console.
> (But that's better the case anyway, as explained in
> http://cygwin.com/1.7/cygwin-ug-net/setup-locale.html#setup-locale-problems)
This would mean you could no longer effectively invoke the cygwin.bat
or cygwinutf.bat scripts within a Windows console and get the proper
charset? That would not be good.
> 3. Change rlogin to call setlocale(LC_ALL, ""); at the start of
> main.
You answered this "no" yourself in the other mail:
> The problem is this: rlogin or ssh work just fine on any other system
> even if they don't use setlocale().
Because they just transfer byte streams, agnostic of any encoding issues.
This approach should work in general and I wonder what exactly makes the
difference in this case, but I have a rough idea (see below).
> The reason is that the terminal
> window is an independent process from the rlogin/ssh process, while in
> our case, the Windows console is managed by the running application
> itself. ...
I had the impression that it's not strictly the application, but the
cygwin dll being used by the application. This makes a big difference.
I am even speculating that the problem might just vanish once rlogin and
telnet are just recompiled. I tried to check this myself but my compilation
failed as I reported in another mail.
Thomas
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -