Bug#655589: screen: corrupt display after resuming a session

[Vincent Lefevre]

Package: screen
Version: 4.0.3-14
Severity: normal

With the attached file mscreen2.log (obtained from Xterm log)
and UTF-8 locales:

1. screen sh -c "cat mscreen2.log; sleep 999"
2. Detach the session.
3. Resume the session.

After (1), I get:

q:Quit d:Del u:Undel s:Save m:Mail r:Reply g:Group ?:Help
1 N Jan 12 us...@domain.in ( 22) mail 1
2 N Jan 12 us...@domain.in ( 0K) tr:re: CONFIRMATIONNN‏NN‏N‏‏NN‏N‏‏N

After (3), I get:

1 N Jan 12 us...@domain.in ( 22) mail 1
2 N Jan 12 us...@domain.in ( 0K) tr:re: CONFIRMATION

This is different! In particular, the first line has disappeared.

Note: the UTF-8 seems to be valid (iconv doesn't complain).

To try directly with Mutt, see the attached file mscreen2, which
is a mbox file telling what to do.

-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages screen depends on:
ii dpkg 1.16.1.2
ii install-info 4.13a.dfsg.1-8
ii libc6 2.13-24
ii libncursesw5 5.9-4
ii libpam0g 1.1.3-6

screen recommends no packages.

screen suggests no packages.

-- no debconf information

[Axel Beckert]

found 655589 4.1.0~20110819git450e8f3-1
tag 655589 + confirmed
kthxbye

Hi Vincent,

Vincent Lefevre wrote:
> With the attached file mscreen2.log (obtained from Xterm log)
> and UTF-8 locales:
>
> 1. screen sh -c "cat mscreen2.log; sleep 999"
> 2. Detach the session.
> 3. Resume the session.
>
> After (1), I get:
>
> q:Quit d:Del u:Undel s:Save m:Mail r:Reply g:Group ?:Help
> 1 N Jan 12 us...@domain.in ( 22) mail 1
> 2 N Jan 12 us...@domain.in ( 0K) tr:re: CONFIRMATIONNN‏NN‏N‏‏NN‏N‏‏N
>
> After (3), I get:
>
> 1 N Jan 12 us...@domain.in ( 22) mail 1
> 2 N Jan 12 us...@domain.in ( 0K) tr:re: CONFIRMATION
>
> This is different! In particular, the first line has disappeared.

I can reproduce this here, unfortunately also with the version of
screen currently in Debian experimental.

Workaround (as usual with mutt UTF-8 problems in screen) is to press
Ctrl-L. Works with mutt, but not with cat of the xterm log. (Likely
because cat doesn't react on Ctrl-L while mutt does. ;-)

Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
`- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5



--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Axel Beckert]

Control: forwarded -1 https://savannah.gnu.org/bugs/?43145
Control: retitle -1 screen: corrupt display due to the U+061C character (ARABIC LETTER MARK) or similar

Hi,

Thanks for these additional details and especially the easy
reproducer!

Vincent Lefevre wrote:
> The issue can be reproduced in the following way without needing Mutt:
>
> In a 80-column xterm, execute "screen bash", then
>
> for i in `seq 60` ; do printf 'a\u061c\u061c' ; done ; echo

That's not U+200F (RIGHT-TO-LEFT MARK) which you put in the subject
but U+061C ARABIC LETTER MARK. Updating the bug title accordingly.

> then reduce the terminal window by one line. This has the effect
> to duplicate the prompt and move the status line 2 lines above.

Indeed, can confirm.

Actually for me it already moves the status bar up one line without
resizing the terminal window — actually duplicating it except for the
time in the "upper" status bar which is no more updated.

The terminal window looks like this for me:

abe@c6:~ $ for i in `seq 60` ; do printf 'a\u061c\u061c' ; done ; echo
a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆a̍̎̆
abe@c6:~ $
_

where the a̍̎̆ above comes closest to the glyph shown to me by the uxterm
in which I started the screen session.

The glyph shown to me looks like an "a" with an "u" diacritical and on
top of that three vertical dots. (Tried to replace it above with "a̍̎"
which seems to come optically closest to the glyph I've been seeing.)

And that last underscore shows the position of the cursor shown to me.
I.e. the correct column, but one line lower than it should.

But even when I copy and paste it from the Screen session into a
text-mode Emacs (also inside a Screen session, but a different one),
it is shown me as "a؜؜" (looks like "a__" in Emacs to me), but is
actually still an "a" with 2x U+61C, ARABIC LETTER MARK behind it and
while moving through that string with Ctrl-F the cursor jumps (IMHO
correctly) once two positions forward, then one backward and again two
positions forward.

And the status line(s) looks like this:

c6: 0 bash | 0* bash | 2.34 2.83 3.13 | 23:41:41
c6: 0 bash | 0* bash | 4.55 3.25 3.05 | 23:52:32

I've configured this status line:

hardstatus alwayslastline "%H: %n %t | %w | %l | %c:%s"

And it seems even worse if you have (had) split windows inside the
screen session, i.e. by doing "C-a S" before executing the above
command: the layout is gone afterwards (except for some displayed
leftovers of the delimiter line) and only one is left window left —
the one in which I called that command.

P.S.: I've updated the upstream link from HTTP to HTTPS, i.e. I didn't
change which upstream bug is referenced, just the link's protocol.

Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE

[Vincent Lefevre]

On 2022-05-26 00:19:30 +0200, Axel Beckert wrote:

> Vincent Lefevre wrote:
> > In a 80-column xterm, execute "screen bash", then
> >
> > for i in `seq 60` ; do printf 'a\u061c\u061c' ; done ; echo
>
> That's not U+200F (RIGHT-TO-LEFT MARK) which you put in the subject
> but U+061C ARABIC LETTER MARK. Updating the bug title accordingly.

Indeed. The U+200F text came from the original bug report.

If I replace \u061c by \u200f above, I cannot reproduce the issue.
U+200F is in the "combining" table, but it was already there in 2009.
Perhaps it is more complex to see if the bug can still be reproduced
with this character (I should try again with the character unfiltered
in Mutt).

[...]

> The glyph shown to me looks like an "a" with an "u" diacritical and on
> top of that three vertical dots. (Tried to replace it above with "a̍̎"
> which seems to come optically closest to the glyph I've been seeing.)

I don't think that this is some kind of diacritical. In my case,
it looks like an "a" and a dotted square in the same cell, perhaps
because the wcwidth of U+061C is 0.

[...]

> But even when I copy and paste it from the Screen session into a
> text-mode Emacs (also inside a Screen session, but a different one),
> it is shown me as "a؜؜" (looks like "a__" in Emacs to me), but is
> actually still an "a" with 2x U+61C, ARABIC LETTER MARK behind it and
> while moving through that string with Ctrl-F the cursor jumps (IMHO
> correctly) once two positions forward, then one backward and again two
> positions forward.

That may be because arabic is a right-to-left script, so the two
U+061C characters appear right-to-left.

> P.S.: I've updated the upstream link from HTTP to HTTPS, i.e. I didn't
> change which upstream bug is referenced, just the link's protocol.

Thanks.

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Vincent Lefevre]

On 2022-05-26 01:07:19 +0200, Vincent Lefevre wrote:
> If I replace \u061c by \u200f above, I cannot reproduce the issue.
> U+200F is in the "combining" table, but it was already there in 2009.

In the Debian package, if I add "{ 0x061C, 0x061C }," to
the "combining" table in encoding.c, this makes the issue
with this character disappear. But I don't know whether
this is the right fix.