Debian Bug report logs - #254316
ncurses-base: workaround for screen's handling of register sgr0 isn't quite right

version graph

Package: ncurses-base; Maintainer for ncurses-base is Craig Small <csmall@debian.org>; Source for ncurses-base is src:ncurses.

Reported by: Geoffrey Lee <glee@bluesat.unsw.edu.au>

Date: Mon, 14 Jun 2004 09:33:07 UTC

Severity: normal

Tags: l10n, sid, upstream

Fixed in version ncurses/5.4-5

Done: Daniel Jacobowitz <dan@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#254316; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to Geoffrey Lee <glee@bluesat.unsw.edu.au>:
New Bug report received and forwarded. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Geoffrey Lee <glee@bluesat.unsw.edu.au>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: xterm: CJK font fails after running slang/ncurses program
Date: Mon, 14 Jun 2004 17:22:40 +0800
Package: xterm
Version: 4.3.0.dfsg.1-4
Severity: normal
Tags: sid l10n

Hi


The latest xterm seems to be able to display CJK characters.  However,
I found that after running a slang / ncurses application, the characters
become garbled again.  

I've tested this with traditional Chinese and Japanese fonts but I have no
reason to believe that Korean and Simplified Chinese won't be broken too.

To reproduce simply start xterm and if your directory has a file with a CJK
name you should be able to see the file displayed in the appropriate font.
Next start something like mutt (which uses ncurses) or whiptail, and then
exit.  Then if you do the ls the text will become garbled for CJK.

BTW, since mutt has a Chinese translation ... when I enter mutt I found that
the Chinese translation is garbled too.  So it seems to happen not at 
program exit (which would be improper cleanup) but during invocation of
a slang / ncurses application.

This does not happen with rxvt-ml whether the terminal type is set to 
rxvt or xterm which leads me to believe it is a bug in xterm.


	- g.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-rc2
Locale: LANG=zh_TW.Big5, LC_CTYPE=zh_TW.Big5 (ignored: LC_ALL set to zh_TW.Big5)

Versions of packages xterm depends on:
ii  libc6                     2.3.2.ds1-13   GNU C Library: Shared libraries an
ii  libexpat1                 1.95.6-8       XML parsing C library - runtime li
ii  libfontconfig1            2.2.2-2        generic font configuration library
ii  libfreetype6              2.1.7-2.1      FreeType 2 font engine, shared lib
ii  libice6                   4.3.0.dfsg.1-4 Inter-Client Exchange library
ii  libncurses5               5.4-4          Shared libraries for terminal hand
ii  libsm6                    4.3.0.dfsg.1-4 X Window System Session Management
ii  libxaw7                   4.3.0.dfsg.1-4 X Athena widget set library
ii  libxext6                  4.3.0.dfsg.1-4 X Window System miscellaneous exte
ii  libxft2                   2.1.2-6        FreeType-based font drawing librar
ii  libxmu6                   4.3.0.dfsg.1-4 X Window System miscellaneous util
ii  libxpm4                   4.3.0.dfsg.1-4 X pixmap library
ii  libxrender1               0.8.3-7        X Rendering Extension client libra
ii  libxt6                    4.3.0.dfsg.1-4 X Toolkit Intrinsics
ii  xlibs                     4.3.0.dfsg.1-4 X Window System client libraries m
ii  xlibs-data                4.3.0.dfsg.1-4 X Window System client data

-- no debconf information



Message sent on to Geoffrey Lee <glee@bluesat.unsw.edu.au>:
Bug#254316. Full text and rfc822 format available.

Message #8 received at 254316-submitter@bugs.debian.org (full text, mbox):

From: Thomas Dickey <dickey@radix.net>
To: Geoffrey Lee <glee@bluesat.unsw.edu.au>, 254316-submitter@bugs.debian.org
Subject: Re: Bug#254316: xterm: CJK font fails after running slang/ncurses program
Date: Mon, 14 Jun 2004 06:29:48 -0400
[Message part 1 (text/plain, inline)]
On Mon, Jun 14, 2004 at 11:40:11AM +0200, Geoffrey Lee wrote:
> Package: xterm
> Version: 4.3.0.dfsg.1-4
> Severity: normal
> Tags: sid l10n
> 
> Hi
> 
> 
> The latest xterm seems to be able to display CJK characters.  However,

"latest" implies that you have used a previous version of xterm,
using the same locale settings and that works.

> Debian Release: testing/unstable
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: i386 (i686)
> Kernel: Linux 2.6.7-rc2
> Locale: LANG=zh_TW.Big5, LC_CTYPE=zh_TW.Big5 (ignored: LC_ALL set to zh_TW.Big5)

That locale might work with luit (a helper program for xterm).
But there is no mention of luit in this report.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
[Message part 2 (application/pgp-signature, inline)]

Message sent on to Geoffrey Lee <glee@bluesat.unsw.edu.au>:
Bug#254316. Full text and rfc822 format available.

Message #11 received at 254316-submitter@bugs.debian.org (full text, mbox):

From: Geoffrey Lee <glee@bluesat.unsw.edu.au>
To: Thomas Dickey <dickey@radix.net>
Cc: 254316-submitter@bugs.debian.org
Subject: Re: Bug#254316: xterm: CJK font fails after running slang/ncurses program
Date: Tue, 15 Jun 2004 00:48:38 +1000
On Mon, Jun 14, 2004 at 06:29:48AM -0400, Thomas Dickey wrote:
> > Hi
> > 
> > 
> > The latest xterm seems to be able to display CJK characters.  However,
> 
> "latest" implies that you have used a previous version of xterm,
> using the same locale settings and that works.
> 


Hrm.  Perhaps I should have chosen words more carefully.  I have not used
a previous version of xterm before.  Previous versions which I have used 
did not support such characters.   Sorry if I had confused anyone.


> > Debian Release: testing/unstable
> >   APT prefers unstable
> >   APT policy: (500, 'unstable')
> > Architecture: i386 (i686)
> > Kernel: Linux 2.6.7-rc2
> > Locale: LANG=zh_TW.Big5, LC_CTYPE=zh_TW.Big5 (ignored: LC_ALL set to zh_TW.Big5)
> 
> That locale might work with luit (a helper program for xterm).
> But there is no mention of luit in this report.
> 


I read the manpage and it says the current xterm should invoke luit when
necessary.  Anyway even if I invoke it manually it is even worse, because
then the characters become garbled.

But anyway now that I check it has already been invoked automatically:

(from a rxvt window)

 glee@anakin ~ $ ps -ef | grep luit
glee      6168  6146  0 22:38 pts/669  00:00:00 grep luit
glee@anakin ~ $ xterm &
[1] 6170
glee@anakin ~ $ ps -ef | grep luit
glee      6171  6170  0 22:39 pts/673  00:00:00 /usr/X11R6/bin/luit
glee      6178  6146  0 22:39 pts/669  00:00:00 grep luit
glee@anakin ~ $ 


So, if that's true, does that mean it is luit related and not xterm related?
(if so then please reassign, thanks.)


	- g.
-- 
char p[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
  "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
  "\x80\xe8\xdc\xff\xff\xff/bin/sh";



Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#254316; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to Juliusz Chroboczek <jch@pps.jussieu.fr>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. Full text and rfc822 format available.

Message #16 received at 254316@bugs.debian.org (full text, mbox):

From: Juliusz Chroboczek <jch@pps.jussieu.fr>
To: 254316@bugs.debian.org
Cc: Geoffrey Lee <glee@bluesat.unsw.edu.au>, Thomas Dickey <dickey@radix.net>
Subject: Re: CJK font fails after running slang/ncurses program
Date: 25 Jun 2004 22:03:03 +0200
Hi Thomas!

>> The latest xterm seems to be able to display CJK characters.
>> However, I found that after running a slang / ncurses application,
>> the characters become garbled again.

Geoffrey: as a workaround, you may do

  TERM=kterm; export TERM

> So, if that's true, does that mean it is luit related and not xterm
> related?

It's a bug in terminfo that I've alreay reported to you, Thomas, when
I first wrote luit.  In the xterm cap, there's the following:

  enacs=\E(\B\E)0
  smacs=^N
  rmacs=^O

This clobbers G1.  It works in ISO 8859-n locales because there's a
workaround in luit (luit uses G2 instead of G1 for such locales).
While there's in principle nothing preventing the same workaround to
work for Big5 locales, the problem with EUC will remain.

The proper fix is to use the following in the xterm cap:

  enacs=
  rmacs=\E(B
  smacs=\E(0

This only uses G0, and works in any locale that has ASCII in G0, which
includes all standard Unix locales.

Branden: please reassign this to ncurses-base and mark it upstream.

                                        Juliusz



Message sent on to Geoffrey Lee <glee@bluesat.unsw.edu.au>:
Bug#254316. Full text and rfc822 format available.

Message #19 received at 254316-submitter@bugs.debian.org (full text, mbox):

From: Thomas Dickey <dickey@radix.net>
To: Juliusz Chroboczek <jch@pps.jussieu.fr>
Cc: 254316-submitter@bugs.debian.org
Subject: Re: CJK font fails after running slang/ncurses program
Date: Fri, 25 Jun 2004 18:36:15 -0400
[Message part 1 (text/plain, inline)]
On Fri, Jun 25, 2004 at 10:03:03PM +0200, Juliusz Chroboczek wrote:
> It's a bug in terminfo that I've alreay reported to you, Thomas, when

You did raise the issue, but didn't point out an example where it breaks. 
(There were 3-4 people who wanted this changed, iirc, at one time or another
asking to make the change to "xterm", "xterm-xfree86", "vt220" and "vt100",
and my more recent replies suggest making a new terminfo entry rather than
change one that's used widely).

I read what I could find on EUC, but don't see where it uses codes 0-31 for
printable text.  For instance this (which I recall reading before):

	http://lfw.org/text/jp.htm

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#254316; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to Juliusz Chroboczek <jch@pps.jussieu.fr>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. Full text and rfc822 format available.

Message #24 received at 254316@bugs.debian.org (full text, mbox):

From: Juliusz Chroboczek <jch@pps.jussieu.fr>
To: Thomas Dickey <dickey@radix.net>
Cc: 254316@bugs.debian.org, 254316-submitter@bugs.debian.org
Subject: Re: CJK font fails after running slang/ncurses program
Date: 26 Jun 2004 00:56:26 +0200
TD> I read what I could find on EUC, but don't see where it uses codes 0-31 for
TD> printable text.

It doesn't use codes 0-31.

EUC is an application of of ISO 2022 that uses G1, which is one of the
registers of the ISO 2022 virtual machine.  For example, in EUC-CN, G1
points at GB-2312.

ESC ) 0 is an ISO 2022 escape sequence.  Its purpose is to set G1 to
the DEC special character set.

(Now DEC special happens to be encoded in positions 0-31 of XTerm-
encoded fonts, but that's an implementation detail.)

Now it so turns out that luit implements enough of ISO 2022 to
actually have a G1 register.  In order to display EUC correctly, this
register needs to be set to a particular value (GB 2312 in the case of
EUC-CN).  When an application sends the enacs sequence, it clobbers
G1, and hence causes luit to garble EUC input.

Please note that luit is doing as requested.  The problem is not in
luit, it's not in XTerm, it's not even in termcap; it's in the morass
of complexity that some mindless jerk who'll be first against the wall
when the revolution comes standardised as ISO 2022.

There are two solutions.  Don't use ISO 2022 and have people switch to
UTF-8, which is what we've been trying to do for a decade or so.  Or
change the XTerm termcap to something that works in EUC locales.

I hope this clarifies things,

                                        Juliusz



Message sent on to Geoffrey Lee <glee@bluesat.unsw.edu.au>:
Bug#254316. Full text and rfc822 format available.

Message sent on to Geoffrey Lee <glee@bluesat.unsw.edu.au>:
Bug#254316. Full text and rfc822 format available.

Message #30 received at 254316-submitter@bugs.debian.org (full text, mbox):

From: Thomas Dickey <dickey@radix.net>
To: Juliusz Chroboczek <jch@pps.jussieu.fr>
Cc: 254316-submitter@bugs.debian.org
Subject: Re: CJK font fails after running slang/ncurses program
Date: Fri, 25 Jun 2004 19:08:52 -0400
[Message part 1 (text/plain, inline)]
On Sat, Jun 26, 2004 at 12:56:26AM +0200, Juliusz Chroboczek wrote:
> TD> I read what I could find on EUC, but don't see where it uses codes 0-31 for
> TD> printable text.
> 
> It doesn't use codes 0-31.
> 
> EUC is an application of of ISO 2022 that uses G1, which is one of the
> registers of the ISO 2022 virtual machine.  For example, in EUC-CN, G1
> points at GB-2312.
> 
> ESC ) 0 is an ISO 2022 escape sequence.  Its purpose is to set G1 to
> the DEC special character set.
> 
> (Now DEC special happens to be encoded in positions 0-31 of XTerm-
> encoded fonts, but that's an implementation detail.)

yes (and xterm's users think they're encoded in 96-126; "real" 0-31 are
control characters).
 
> Now it so turns out that luit implements enough of ISO 2022 to
> actually have a G1 register.  In order to display EUC correctly, this
> register needs to be set to a particular value (GB 2312 in the case of
> EUC-CN).  When an application sends the enacs sequence, it clobbers
> G1, and hence causes luit to garble EUC input.

...and since it has to be set to a particular value (and because there's
no good method to determine what it was - or isn't there?) you suggest
that the application not use G1 for anything else.  (Your initial report
only stated that it would break the 2022 state, btw).

But (now that I'm thinking along those lines), luit knows what the particular
value is, and in principle could have massaged the ^O into a string that
would select BG 2312 back into G1.

(Ignoring the issue of being a bit late to modify luit, I'm curious if
there was some reason why that couldn't work).
 
> Please note that luit is doing as requested.  The problem is not in
> luit, it's not in XTerm, it's not even in termcap; it's in the morass
> of complexity that some mindless jerk who'll be first against the wall
> when the revolution comes standardised as ISO 2022.

( google suggests 2022 has many fans ;-)

> There are two solutions.  Don't use ISO 2022 and have people switch to
> UTF-8, which is what we've been trying to do for a decade or so.  Or
> change the XTerm termcap to something that works in EUC locales.
> 
> I hope this clarifies things,
> 
>                                         Juliusz

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
[Message part 2 (application/pgp-signature, inline)]

Message sent on to Geoffrey Lee <glee@bluesat.unsw.edu.au>:
Bug#254316. Full text and rfc822 format available.

Message #33 received at 254316-submitter@bugs.debian.org (full text, mbox):

From: Juliusz Chroboczek <jch@pps.jussieu.fr>
To: Thomas Dickey <dickey@radix.net>
Cc: 254316-submitter@bugs.debian.org
Subject: Re: CJK font fails after running slang/ncurses program
Date: 26 Jun 2004 01:37:36 +0200
TD> ...and since it has to be set to a particular value (and because there's
TD> no good method to determine what it was - or isn't there?) you suggest
TD> that the application not use G1 for anything else.

Exactly.  (There is none.)

I suggest that the application use smacs=\E(0, which sets G0 to point
at DEC Special instead of G1.  Now in principle the problem is the
same with G0; but it so turns out that all Unix locales (even EUC-JP)
set G0 to point at US-ASCII, which can be recovered with rmacs=\E(B.

TD> But (now that I'm thinking along those lines), luit knows what the
TD> particular value is, and in principle could have massaged the ^O
TD> into a string that would select BG 2312 back into G1.

^N is a locking shift into G1 mode, and ^O is a return to G0 mode.  In
order to print a DEC Special character, you can either select DEC
Special into G0, or else select DEC Special into G1 and shift into G1
mode.

Now suppose luit has GB-2312 in G1, the application selects DEC
Special into G1, shifts into G1, prints a character, and then shifts
back into G0.  How do I know whether it actually meant to keep DEC
Special in G1 for further usage, or whether it was only kidding?

(Well, I could cheat: I know what the xterm termcap entry is like, and
that's enough information to work that out.  But I'm not volunteering.)

>> the morass of complexity that some mindless jerk who'll be first
>> against the wall when the revolution comes standardised as ISO 2022.

TD> ( google suggests 2022 has many fans ;-)

We'll use a larger wall.

                                        Juliusz



Message sent on to Geoffrey Lee <glee@bluesat.unsw.edu.au>:
Bug#254316. Full text and rfc822 format available.

Message #36 received at 254316-submitter@bugs.debian.org (full text, mbox):

From: Thomas Dickey <dickey@his.com>
To: Juliusz Chroboczek <jch@pps.jussieu.fr>, 254316-submitter@bugs.debian.org
Subject: Re: Bug#254316: CJK font fails after running slang/ncurses program
Date: Wed, 7 Jul 2004 20:41:15 -0400
[Message part 1 (text/plain, inline)]
On Fri, Jun 25, 2004 at 10:30:12PM +0200, Juliusz Chroboczek wrote:
 
> This clobbers G1.  It works in ISO 8859-n locales because there's a
> workaround in luit (luit uses G2 instead of G1 for such locales).
> While there's in principle nothing preventing the same workaround to
> work for Big5 locales, the problem with EUC will remain.
> 
> The proper fix is to use the following in the xterm cap:
> 
>   enacs=
>   rmacs=\E(B
>   smacs=\E(0
> 
> This only uses G0, and works in any locale that has ASCII in G0, which
> includes all standard Unix locales.

however - I noticed this week that my workaround for screen's handling
of sgr0 (termcap "me") doesn't work for this case.  I made a fix tonight
(since I'm looking for similar issues), and _that_ will be in my next
ncurses patch -- but I'm not certain when I'll finish resolving ongoing
breakage in the form library (perhaps this weekend).
 
> Branden: please reassign this to ncurses-base and mark it upstream.

that's the proper place, since I've already made the changes in both xterm
and ncurses

-- 
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian X Strike Force <debian-x@lists.debian.org>:
Bug#254316; Package xterm. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <debian-x@lists.debian.org>. Full text and rfc822 format available.

Message #41 received at 254316@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: 254316@bugs.debian.org, control@bugs.debian.org
Cc: ncurses-base@packages.debian.org
Subject: Re: Bug#254316: CJK font fails after running slang/ncurses program
Date: Sat, 10 Jul 2004 16:34:12 -0500
[Message part 1 (text/plain, inline)]
reassign 254316 ncurses-base
retitle 254316 ncurses-base: workaround for screen's handling of register sgr0 isn't quite right
tag 254316 + upstream
thanks

Sorry for the unhelpful bug title; I don't quite understand *exactly* what
the problem is.  Nevertheless, my faith in Thomas and Juliusz is strong.

On Wed, Jul 07, 2004 at 08:41:15PM -0400, Thomas Dickey wrote:
> On Fri, Jun 25, 2004 at 10:30:12PM +0200, Juliusz Chroboczek wrote:
>  
> > This clobbers G1.  It works in ISO 8859-n locales because there's a
> > workaround in luit (luit uses G2 instead of G1 for such locales).
> > While there's in principle nothing preventing the same workaround to
> > work for Big5 locales, the problem with EUC will remain.
> > 
> > The proper fix is to use the following in the xterm cap:
> > 
> >   enacs=
> >   rmacs=\E(B
> >   smacs=\E(0
> > 
> > This only uses G0, and works in any locale that has ASCII in G0, which
> > includes all standard Unix locales.
> 
> however - I noticed this week that my workaround for screen's handling
> of sgr0 (termcap "me") doesn't work for this case.  I made a fix tonight
> (since I'm looking for similar issues), and _that_ will be in my next
> ncurses patch -- but I'm not certain when I'll finish resolving ongoing
> breakage in the form library (perhaps this weekend).
>  
> > Branden: please reassign this to ncurses-base and mark it upstream.
> 
> that's the proper place, since I've already made the changes in both xterm
> and ncurses
> 
> -- 
> Thomas E. Dickey <dickey@invisible-island.net>
> http://invisible-island.net
> ftp://invisible-island.net

-- 
G. Branden Robinson                |     There is resilient security in
Debian GNU/Linux                   |     openness, and brittle security in
branden@debian.org                 |     secrecy.
http://people.debian.org/~branden/ |     -- Bruce Schneier
[signature.asc (application/pgp-signature, inline)]

Bug reassigned from package `xterm' to `ncurses-base'. Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Changed Bug title. Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Tags added: upstream Request was from Branden Robinson <branden@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Daniel Jacobowitz <ncurses-maint@debian.org>:
Bug#254316; Package ncurses-base. Full text and rfc822 format available.

Acknowledgement sent to Branden Robinson <branden@debian.org>:
Extra info received and forwarded to list. Copy sent to Daniel Jacobowitz <ncurses-maint@debian.org>. Full text and rfc822 format available.

Message #52 received at 254316@bugs.debian.org (full text, mbox):

From: Branden Robinson <branden@debian.org>
To: 254316@bugs.debian.org
Subject: [dickey@radix.net: Re: Bug#254316: CJK font fails after running slang/ncurses program]
Date: Mon, 12 Jul 2004 00:53:34 -0500
[Message part 1 (text/plain, inline)]
Forwarding Thomas's reply to the bug so the package maintainer can see it.

----- Forwarded message from Thomas Dickey <dickey@radix.net> -----

From: Thomas Dickey <dickey@radix.net>
To: Branden Robinson <branden@debian.org>
Subject: Re: Bug#254316: CJK font fails after running slang/ncurses program
Date: Sat, 10 Jul 2004 19:40:38 -0400 (EDT)
Message-Id: <200407102340.i6ANec4a028289@saltmine.radix.net>
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (SunOS/5.8 (sun4u))
X-Spam-Status: No, hits=-4.9 required=4.0 tests=BAYES_00 autolearn=ham 
	version=2.63

In article <2gxTz-7Td-37@gated-at.bofh.it> you wrote:

> --lvzXnIqIiPbDUI27
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable

> reassign 254316 ncurses-base
> retitle 254316 ncurses-base: workaround for screen's handling of register sgr0 isn't quite right
> tag 254316 + upstream
> thanks

> Sorry for the unhelpful bug title; I don't quite understand *exactly* what
> the problem is.  Nevertheless, my faith in Thomas and Juliusz is strong.

sgr0 is the character string that an application sends to turn off the video
attributes.  It happens that screen uses termcap, and ncurses provides that -
based on terminfo.  Usually termcap strings are one-one with terminfo, or a
subset (termcap provides only rudimentary parameter substitution).

But sgr0 is special - it's a case where terminfo and termcap are not really
compatible.  (At least that's what screen's maintainer told me a few years
ago):

screen gets confused (produces ugly display) if sgr0 contains strings that turn
off line-drawing (because it uses termcap and insists that the strings have
termcap's semantics).  I made a work around for the cases I've been using a
while back, but it didn't cover the case that Juliusz needs.  So that's a
library fix needed to avoid some more bug reports when the change to xterm's
terminfo is incorporated.

I think Daniel will be able to follow all that...

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

----- End forwarded message -----

-- 
G. Branden Robinson                |      The noble soul has reverence for
Debian GNU/Linux                   |      itself.
branden@debian.org                 |      -- Friedrich Nietzsche
http://people.debian.org/~branden/ |
[signature.asc (application/pgp-signature, inline)]

Reply sent to Daniel Jacobowitz <dan@debian.org>:
You have taken responsibility. Full text and rfc822 format available.

Notification sent to Geoffrey Lee <glee@bluesat.unsw.edu.au>:
Bug acknowledged by developer. Full text and rfc822 format available.

Message #57 received at 254316-close@bugs.debian.org (full text, mbox):

From: Daniel Jacobowitz <dan@debian.org>
To: 254316-close@bugs.debian.org
Subject: Bug#254316: fixed in ncurses 5.4-5
Date: Sun, 12 Jun 2005 12:47:06 -0400
Source: ncurses
Source-Version: 5.4-5

We believe that the bug you reported is fixed in the latest version of
ncurses, which is due to be installed in the Debian FTP archive:

libncurses5-dbg_5.4-5_i386.deb
  to pool/main/n/ncurses/libncurses5-dbg_5.4-5_i386.deb
libncurses5-dev_5.4-5_i386.deb
  to pool/main/n/ncurses/libncurses5-dev_5.4-5_i386.deb
libncurses5_5.4-5_i386.deb
  to pool/main/n/ncurses/libncurses5_5.4-5_i386.deb
libncursesw5-dbg_5.4-5_i386.deb
  to pool/main/n/ncurses/libncursesw5-dbg_5.4-5_i386.deb
libncursesw5-dev_5.4-5_i386.deb
  to pool/main/n/ncurses/libncursesw5-dev_5.4-5_i386.deb
libncursesw5_5.4-5_i386.deb
  to pool/main/n/ncurses/libncursesw5_5.4-5_i386.deb
ncurses-base_5.4-5_all.deb
  to pool/main/n/ncurses/ncurses-base_5.4-5_all.deb
ncurses-bin_5.4-5_i386.deb
  to pool/main/n/ncurses/ncurses-bin_5.4-5_i386.deb
ncurses-term_5.4-5_all.deb
  to pool/main/n/ncurses/ncurses-term_5.4-5_all.deb
ncurses_5.4-5.diff.gz
  to pool/main/n/ncurses/ncurses_5.4-5.diff.gz
ncurses_5.4-5.dsc
  to pool/main/n/ncurses/ncurses_5.4-5.dsc



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 254316@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Daniel Jacobowitz <dan@debian.org> (supplier of updated ncurses package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 12 Jun 2005 11:17:54 -0400
Source: ncurses
Binary: ncurses-base lib64ncurses5 libncursesw5-dev libncursesw5-dbg ncurses-bin libncurses5 libncursesw5 libncurses5-dev ncurses-term libncurses5-dbg lib64ncurses5-dev
Architecture: source i386 all
Version: 5.4-5
Distribution: unstable
Urgency: low
Maintainer: Daniel Jacobowitz <ncurses-maint@debian.org>
Changed-By: Daniel Jacobowitz <dan@debian.org>
Description: 
 libncurses5 - Shared libraries for terminal handling
 libncurses5-dbg - Debugging/profiling libraries for ncurses
 libncurses5-dev - Developer's libraries and docs for ncurses
 libncursesw5 - Shared libraries for terminal handling (wide character support)
 libncursesw5-dbg - Debugging/profiling libraries for ncurses
 libncursesw5-dev - Developer's libraries for ncursesw
 ncurses-base - Descriptions of common terminal types
 ncurses-bin - Terminal-related programs and man pages
 ncurses-term - Additional terminal type definitions
Closes: 55637 110586 254316 257872 259253 265631 265784 273463 280687 283059 295083 301376 305704
Changes: 
 ncurses (5.4-5) unstable; urgency=low
 .
   * Use quilt to manage patches.
   * Update to upstream patch level 20050604.
     - Hurd build fix merged upstream.
     - Part of explicitly signed character patch merged upstream.
     - Corrected man page for mouseinterval (Closes: #280687).
     - Improved support for the zn_CH.GBK locale (Closes: #301376).
     - Improved terminfo entry for putty (Closes: #305704).
     - Explain the reference to ded(1) on the default_colors(3ncurses)
       man page (Closes: #295083).
     - Reset xterm mouse mode in various terminfo entries (Closes: #55637).
     - Check the size of the terminal after newterm() (Closes: #265631).
   * Updated xterm terminfo entry from xterm 200.  Combined with the
     upstream patch level, this (Closes: #254316).
   * Install the examples in libncurses5-dev again (Closes: #257872).
   * Remove use of test -a in ncurses-base and ncurses-term preinsts
     (Closes: #259253).
   * Enable gpm support (Closes: #110586).
   * Load libgpm.so.1 instead of libgpm.so.
   * Merge the Debian rxvt terminfo entry with upstream changes.
     - Upstream added cnorm to rxvt's reset string, so that the block cursor
       is restored if civis was used (Closes: #265784).
   * Fix the default bindings for F1-F4 in rxvt.
   * Use smkx instead of rmkx in rxvt's reset string, so that reset does
     not leave the keypad in the wrong state.
   * Move libncursesw.so.5 to /lib (Closes: #273463).
   * Added a patch from NIIBE Yutaka to support cross-compilation between
     two Debian systems (Closes: #283059).
   * Correct the section for the inwstr(3ncurses) man page.
   * Add myself to Uploaders.
   * Correct sections on the tack(1) man page.
   * Use symlinks instead of hardlinks for the terminfo database.
   * Remove a four-year-old workaround for an ia64 gcc bug.
   * Update shlibs file to (>= 5.4-5).
   * Configure using --disable-lp64 for compatibility on 64-bit architectures.
Files: 
 ed9623c2b270a187fa46c0b3cc04eb12 883 libs standard ncurses_5.4-5.dsc
 435ba55597cb03d7b09f97933d0be1dd 799336 libs standard ncurses_5.4-5.diff.gz
 5b37214b39694b3d0369c136f3cc893a 288672 base required libncurses5_5.4-5_i386.deb
 6d4bfb5f1ed426a74d7c6532213761ab 1247002 libdevel optional libncurses5-dev_5.4-5_i386.deb
 926a22295e7753f9f3c947d536ff5a56 5266072 libdevel extra libncurses5-dbg_5.4-5_i386.deb
 dd88ae6881a696c2391c78a11b05a675 304144 libs standard libncursesw5_5.4-5_i386.deb
 61b9db3fa98029e1c58e097b9f999876 416970 libdevel optional libncursesw5-dev_5.4-5_i386.deb
 123e8306059e277951db311ef3b00dfe 5800478 libdevel extra libncursesw5-dbg_5.4-5_i386.deb
 e4bd77cd68251ec9e0b8c71fad38b877 207632 base required ncurses-bin_5.4-5_i386.deb
 83464ad6d36b54aadb09d4061182fcc6 12170 base required ncurses-base_5.4-5_all.deb
 5d9a94886bc9d4268c50b088c62e20b8 277774 admin standard ncurses-term_5.4-5_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCrGOEbgOPXuCjg3cRAugAAJwNh4F07jmdbfRxOG4WGlUZL8pVQwCfQxhr
+9+y4ZMP3m44B/knpDOzB/c=
=mIcU
-----END PGP SIGNATURE-----




Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 23 14:48:38 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.