[Top][All Lists]

[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

From: Dan Mick
Subject: [Bug-readline] rl_initialize will always write to stdout even if no readline services yet requested
Date: Fri, 14 Jun 2013 16:18:10 -0700
User-agent: 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.

Version: 6.2
Machine: Dell 64-bit Intel
build flags: as in quantal package libreadline6 Version: 6.2-9

Version:  6.0
Machine: qemu-kvm 64-bit VM
Flags: default package readline-6.0.4.el6.x86_64

reply via email to

[Prev in Thread] Current Thread [Next in Thread]