Date: Tue, 21 Apr 2009 17:23:34 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: [1.7] Updated: cygwin-1.7.0-45
Message-ID: <20090421152334.GH8722@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <20090402171059.GE12738@calimero.vinschen.de> <20090331111757.GA22043@calimero.vinschen.de> <200904031037.n33Ab4Ma001073@mail.bln1.bf.nsn-intra.net> <20090403145139.GJ12738@calimero.vinschen.de> <200904211025.n3LAPf7a022955@mail.bln1.bf.nsn-intra.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200904211025.n3LAPf7a022955@mail.bln1.bf.nsn-intra.net>
User-Agent: Mutt/1.5.19 (2009-02-20)
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On Apr 14 19:08, Thomas Wolff wrote:
> On April 14, Corinna Vinschen wrote:
> 
> > > ... 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.
> > 
> > This approach is now implemented in 1.7.0-46.  Please give it a try.
> 
> UTF-8 after rlogin/telnet works fine now, thank you.
> 
> There are still a few issues I'd like to report:
> [...]
> With some encodings, bash hangs with sed.exe using 99% CPU time; if I 
> interrupt with ^C, however, the codepage is properly set up. This happens 
> with the "DOS codepages" CP437...CP866 and CP1125, while the "ANSI codepages" 
> CP874 and CP1250...CP1258, the ISO codepages, and the CJK codepages work fine.

This is a real problem.  In the OEM codepages the 0xff character is a
non-breaking space.  Unfortunately there's no way to distinguish between
the (signed) char value 0xff and EOF when it's put as argument into the
ctype functions.  sed has a loop which loops over all blank characters
in the input, basically like this:

  do {
    ch = inchar ();
  } while (isblank (ch);

As soon as inchar() is at the end of the input, it returns EOF == -1.  And
then the loop never stops, because the character value -1 is a blank
character.

However, this appears to be a generic problem with the character with
value 0xff.  If char is signed, its value is -1 and it can't be
distinguished from EOF.

The only solution for this problem is, AFAICS, to treat the character
0xff as a non-character, for which all ctype functions return 0.

This is ugly, but I could not get any of the ctype function to return
non-0 on Linux for this character as well, whatever I tried.

> By the way, maybe it should be mentioned in the user guide that setting the 
> console font to Lucida Console rather than "Raster Fonts" enhances the 
> Unicode font support. Even then I don't get any Arabic/Hebrew/Thai or CJK 
> font display. Do you have a working test setup for those? (I guess so 
> since you support the encodings.)

No, I used charset tables to do this.  I have no font installed which
shows these characters.  I couldn't read them anyway.  For testing
purposes I used od(1).

> ----------------------
> 
> Yet another issue:
> When I hit Backspace on the command line in UTF-8 or CJK modes, the 
> whole line including the prompt is blanked.

I can't reproduce this.  I tried it in bash and tcsh, but backspace
is backspace for me.


Thanks for testing,
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/