Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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
Date: Sun, 6 Jun 2004 12:53:27 +0200
From: Baurjan Ismagulov <ibr AT ata DOT cs DOT hun DOT edu DOT tr>
To: cygwin AT cygwin DOT com
Subject: Re: rxvt, ssh and utf8 - partial success
Message-ID: <20040606105326.GA3589@ata.cs.hun.edu.tr>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <40C09A9B DOT 5060707 AT athensgroup DOT com> <40C0AF05 DOT DBA983C AT dessent DOT net> <20040605124405 DOT GA2352 AT ata DOT cs DOT hun DOT edu DOT tr> <40C2620F DOT 9010009 AT athensgroup DOT com> <40C27FC5 DOT 1080700 AT athensgroup DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline; filename=muttLaYevU
In-Reply-To: <40C27FC5.1080700@athensgroup.com>
User-Agent: Mutt/1.5.6i
X-IsSubscribed: yes

Hello, James,

On Sat, Jun 05, 2004 at 09:21:57PM -0500, James Garrison wrote:
> >>Handling this in rxvt should solve your problem (I wonder if there are
> >>any reasons not to do that).

This was actually an answer to Brian, who wanted to have a single
terminal type for one application (and I share his opinion). But it
seems to apply to your question, too: from
http://google.com/search?q=rxvt+unicode I conclude that rxvt doesn't
handle Unicode. If you try rxvt-unicode I would like to know whether it
works under Cygwin. I've tried it under Debian and couldn't see the
expected symbols when I cat a file encoded in utf-8.


Brian: FWIW, I can't reproduce the less behaviour you've described.
Under Linux both entries work in the same way, which is expected, given
that the terminfo entries are identical except acsc. Perhaps you are
using an older version of terminfo, which has some other differences?
I've tested terminfo 5.3-3.


> I uploaded the rxvt-cygwin terminfo file from Cygwin onto the Linux
> system (into ~/.terminfo/r/rxvt-cygwin).  Setting TERM=rxvt-cygwin now
> allows the curses-based program to draw boxes correctly, but
> apparently some substitution is going on because it's using plain old
> hyphens and vertical bars for lines and plus signs for corners.

I'm not sure what you call partial success, but all this seems to be
irrelevant to your original question.

The byte stream from the input should be treated as Unicode by the
application (=> try rxvt-unicode, or xterm in the Unicode mode, if it
works under Cygwin). I don't think it's terminfo entry that makes the
application output pluses and hyphens (and I can't reproduce this under
Linux; mc printed the codes from acsc using the current font).


> Terminfo doesn't seem to know anything about Unicode as far as I can
> tell (or does it?).  That leads to the question of how putting the
> terminfo file on the Linux system caused the curses-based program to
> output single ASCII characters where previously it was sending Unicode
> sequences... something understood how to interpret the Unicode box-
> drawing characters and replaced them with the nearest ASCII matches
> "+", "|" and '-'.

There are some attempts to produce a Unicode curses library, but I don't
know whether terminfo is involved; it is enough for me if it works with
byte streams.

About ascii instead of Unicode... How do you conclude that the program
(which one?) was sending Unicode sequences before using rxvt-cygwin (=>
what is your locale?).


> However, this IS NOT happening with Unicode quote characters.  Here's
> a snippet from the man page for terminfo itself, as displayed:
> ...
> Those "???" sequences turn out to be \xE2\x80\x99, which is the UTF8
> encoding of the Unicode character "Right Single Quotation Mark)
> (U+2019).

This is not happening with other characters as well, at least not due to
terminfo. Man outputs Unicode -> rxvt displays it (albeit not in a way
you'd like it to). I thinks that in your previous example it was the
application that decided to output ascii instead of characters from
acsc.


With kind regards,
Baurjan.

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