Bug 593799 - strange chars at `yum shell` output
Summary: strange chars at `yum shell` output
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: python
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Dave Malcolm
QA Contact: BaseOS QE - Apps
Depends On:
Blocks: 582655
TreeView+ depends on / blocked
Reported: 2010-05-19 18:00 UTC by Jan Hutař
Modified: 2014-01-21 06:18 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-06-09 17:54:57 UTC

Attachments (Terms of Use)

Description Jan Hutař 2010-05-19 18:00:17 UTC
Description of problem:
Using hexdump, I see strange characters in the `yum shell` output. These were not there (RHEL5). Could these be removed or could you advise me what I'm doing wrong?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. # echo 'config exclude' | yum -y --exclude=kernel shell | grep '^> exclude: kernel'
2. # echo 'config exclude' | yum -y --exclude=kernel shell | grep '^.\+> exclude: kernel'
> exclude: kernel

Actual results:
First command fails to grep

Expected results:
Both commands should work, they would grep the line on RHEL5

Comment 1 Jan Hutař 2010-05-19 18:05:17 UTC
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.|

Might it be any shell miss-configuration?

Comment 2 RHEL Product and Program Management 2010-05-19 18:16:04 UTC
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

Comment 3 James Antill 2010-05-19 19:29:11 UTC
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.

Comment 4 Dave Malcolm 2010-05-25 18:59:39 UTC
(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

Comment 5 RHEL Product and Program Management 2010-07-15 14:51:21 UTC
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. **

Comment 6 Dave Malcolm 2010-09-17 22:00:57 UTC
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|

Comment 7 Dave Malcolm 2010-09-17 22:19:25 UTC
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|

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

Reassigning to "readline"

Comment 8 Miroslav Lichvar 2011-04-22 15:36:58 UTC
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).


Comment 9 Dave Malcolm 2011-06-09 17:54:24 UTC
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
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

     _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)

Comment 10 RHEL Product and Program Management 2011-06-09 17:54:57 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Note You need to log in before you can comment on or make changes to this bug.