X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Fri, 3 Apr 2009 16:51:39 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: [1.7] Updated: cygwin-1.7.0-45
Message-ID: <20090403145139.GJ12738@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20090402171059 DOT GE12738 AT calimero DOT vinschen DOT de> <20090331111757 DOT GA22043 AT calimero DOT vinschen DOT de> <200904031037 DOT n33Ab4Ma001073 AT mail DOT bln1 DOT bf DOT nsn-intra DOT net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200904031037.n33Ab4Ma001073@mail.bln1.bf.nsn-intra.net>
User-Agent: Mutt/1.5.19 (2009-02-20)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Apr  3 12:37, Thomas Wolff wrote:
> [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.]

Worked fine :)

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

I *hope* it's not.  I still see some problems with not having such an
environment setting for the console behaviour.  For instance, in
contrast to using xterm/rxvt/mintty, you *have* to define
`LANG=en_US.UTF-8' to get a UTF-8 capable console, even if you otherwise
wish to work in a "C" locale.  Wouldn't it be awkward to define
LANG=en_US.UTF-8 in the Windows batch file or global environment and
then having to call another `export LANG=C' in one of your profiles?

So, what's better?  Having to set $LANG/LC_ALL/LC_CTYPE twice to
get something like that, or having a distinct environment setting
for the console charset?

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

As I said, the console is handled by the application itself.  Right now,
the console shares the lcoale setting with the application using the
console.

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

No, that's not right.  The locale setting for the console would last
from the first Cygwin parent process started in a console, up to the
last Cygwin child process called by another Cygwin process, without
invoking another native Windows process in the interim.  Every closed
Cygwin process tree works on it's own console-wise, for all practical
purposes.  Start cmd.exe from your bash, and then start bash again, then
these two bashes will not share certain information which is inherited
to Cygwin child processes, inclduing console settings.

Again, the setting of the console would depend on the
LC_ALL/LC_CTYPE/LANG setting when you start the first Cygwin process of
a Cygwin process tree in that console.  It would last for all Cygwin
processes within the same process tree.

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

Right.

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

No, it does not.  The console is using the settings on a per-application
base.  Right now including the current charset...

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

...and you can't change that by recompiling the application.  If you
want console settings which are independent of the application locale
setting, you need to use one of the methods 1 or 2.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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