[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-readline] rl_initialize will always write to stdout even if no read
[Bug-readline] rl_initialize will always write to stdout even if no readline services yet requested
Fri, 14 Jun 2013 16:18:10 -0700
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
Several programs that use libreadline (a python script that imports
readline for purposes of making Python's raw_input() use readline
support, parted) were, in some cases, outputting escape codes to stdout,
even if no user input was requested or processed. These codes
corrupted the expected output of the programs and consumers of it.
This stems from the 'meta-key' support: if the terminal reports it has a
meta key and gives a meta-key enable string, rl_initialize() always
outputs it, whether or not stdin is even a terminal.
(_rl_enable_meta_key()) We noticed difference in behavior between
Ubuntu Quantal and Centos 6.2; this stems from different terminfo
on quantal, infocmp -L | grep meta_on finds nothing
on centos63: meta_on=\E[?1034h
(and indeed this is the code inserted onto stdout)
Our workaround will be to unset TERM in the environment before calling
subprocesses, but I don't know the right architectural solution here.
1) disable this behavior if stdin/stdout are not ttys, and/or
2) defer this level of terminal initialization until/unless the readline
action routines are actually called.
Machine: Dell 64-bit Intel
build flags: as in quantal package libreadline6 Version: 6.2-9
Machine: qemu-kvm 64-bit VM
Flags: default package readline-6.0.4.el6.x86_64
- [Bug-readline] rl_initialize will always write to stdout even if no readline services yet requested,
Dan Mick <=