Bug 593799

Forgot to add:

# echo 'config exclude' | yum -y --exclude=kernel shell | hexdump -C
00000000  53 65 74 74 69 6e 67 20  75 70 20 59 75 6d 20 53  |Setting up Yum S|
00000010  68 65 6c 6c 0a 1b 5b 3f  31 30 33 34 68 3e 20 65  |hell..[?1034h> e|
00000020  78 63 6c 75 64 65 3a 20  6b 65 72 6e 65 6c 0a 3e  |xclude: kernel.>|
00000030  20 4c 65 61 76 69 6e 67  20 53 68 65 6c 6c 0a     | Leaving Shell.|
0000003f

Might it be any shell miss-configuration?

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

This appears to be something from either the "cmd" module or readline, in python...

% yes | python -c 'import cmd; cmd.Cmd().cmdloop()' | hexdump -C | head
00000000  1b 5b 3f 31 30 33 34 68  28 43 6d 64 29 20 2a 2a  |.[?1034h(Cmd) **|
00000010  2a 20 55 6e 6b 6e 6f 77  6e 20 73 79 6e 74 61 78  |* Unknown syntax|
00000020  3a 20 79 0a 28 43 6d 64  29 20 2a 2a 2a 20 55 6e  |: y.(Cmd) *** Un|

...it appears to only happen for the first line, but still.

(Testing on F-13), it happens for:
$ yes | python -c 'import cmd; c = cmd.Cmd(); c.cmdloop()' | hexdump -C|head

but not for:
$ yes | python -c 'import cmd; c = cmd.Cmd(); c.use_rawinput=0 ; c.cmdloop()' | hexdump -C|head

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

It's the act of importing the readline module that does this; a very minimal reproducer (on this F13 box)

$ python -c"import readline" | hexdump -C
00000000  1b 5b 3f 31 30 33 34 68                           |.[?1034h|
00000008

This is a readline bug; it looks like it should not emit those characters when stdout is not a tty.  See bug 304181

Setting "TERM=dumb" works around it:

$ python -c "import readline" | hexdump -C
00000000  1b 5b 3f 31 30 33 34 68                           |.[?1034h|
00000008


$ TERM=dumb python -c "import readline" | hexdump -C
(no output)

Reassigning to "readline"

The upstream readline maintainer suggests to avoid calling rl_initialize() in the python readline module or disable the enable-meta-key option (introduced in readline-6.1).

http://lists.gnu.org/archive/html/bug-readline/2011-04/msg00009.html

There seem to be two possible fixes for this, neither of which I'm happy with.

Removing the call to rl_initialize from python's Modules/readline.c removes the corrupt characters, but I'm worried about the impact of doing so on all readline-using Python code; the comment there is "Initialize (allows .inputrc to override)".

As another approach, I tried adding:
  rl_variable_bind ("enable-meta-key", "off");
to immediately before
  rl_initialize()
within setup_readline in python's Modules/readline.c

Unfortunately, this does not fix the problem.  Upon stepping through rl_variable_bind with gdb, it's clear that "enable-meta-key" does not exist yet in the readline-6.0-3.el6.x86_64 that I'm testing with.

However, I noticed that this variable in readline-6.1 is a wrapper around this global in readline's terminal.c:

  /* Non-zero means the user wants to enable a meta key. */
  int _rl_enable_meta = 1;

This variable is (perhaps unwittingly) visible to the dynamic linker, if not a header:

$ eu-readelf -s /usr/lib64/libreadline.so |grep _rl_enable_meta | grep OBJECT
  442: 0000003b6f2414b4      4 OBJECT  GLOBAL DEFAULT       23 _rl_enable_meta

If I add:
     extern int _rl_enable_meta;
to python's Modules/readline.c

and:
     _rl_enable_meta = 0;

to directly before the invocation of rl_initialize(), then the reproducer is fixed.

Clearly, doing so is going beyond readline's intended API/ABI.

(Further, I suspect that it may lead to breakage on various kinds of terminal)

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.