Red Hat Bugzilla – Bug 593799
strange chars at `yum shell` output
Last modified: 2014-01-21 01:18:00 EST
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):
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
First command fails to grep
Both commands should work, they would grep the line on RHEL5
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?
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
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|
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
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).
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)
Development Management has reviewed and declined this request. You may appeal
this decision by reopening this request.