octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #45509] communications-1.2.1 fails during pack


From: Mike Miller
Subject: [Octave-bug-tracker] [bug #45509] communications-1.2.1 fails during package install in octave-4.0.0
Date: Thu, 30 Jul 2015 19:34:40 +0000
User-agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Firefox/38.0

Follow-up Comment #28, bug #45509 (project octave):

Thanks both of you for testing a few things for me. I think I have a handle on
this, I will try to reproduce a little bit later. I think this bug is going to
mostly affect CentOS (and RHEL) 6 and 7 users.

Here's what I think is happening. Readline has *always* printed out the
terminal code to enable "8-bit meta mode" (named smm), if the terminal has
such a code defined (in the terminfo database).

In CentOS 5, there was no smm defined for xterm, or any terminals in the
entire terminfo database in fact.

In CentOS 6, several xterm* terminals do have smm defined, including the base
"xterm" itself.

Readline version 6.1 added an option to allow the 8-bit meta enable code to be
disabled (enable-meta-key) if the user wants, the default is enabled (if
available, as it has been for years). CentOS 6 has readline 6.0, so there is
no way to bypass this.

Readline version 6.3 fixed this so that the enable-meta code is not sent when
output is not a tty.

Debian and Ubuntu are not affected because they have a different terminfo
database that does not define the smm code for xterm (but does for terms like
"xterm-basic" and "xterm-utf8").

So this is really a bug in readline, and primarily affecting CentOS users who
have an old readline and a terminfo database with this escape sequence enabled
for xterm (and xterm-16color, and xterm-256color, but *not* xterm-color!).

I'll do a little more exploring to confirm all of this, and thanks again for
persisting and helping me figure out which pieces are interacting to make this
happen. I'll think about what would be a decent workaround to protect against
this.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45509>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]