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
implementations:
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.
Suggestions:
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.
quantal:
Version: 6.2
Machine: Dell 64-bit Intel
build flags: as in quantal package libreadline6 Version: 6.2-9
centos63:
Version: 6.0
Machine: qemu-kvm 64-bit VM
Flags: default package readline-6.0.4.el6.x86_64
_______________________________________________
Bug-readline mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-readline
