This is the mail archive of the cygwin 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: [1.7] Updated: cygwin-1.7.0-45


[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/


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