lib/44599: libedit acts as if no data read if editmode is turned off

[steve.vernon%citrix.com@localhost]

>Number:         44599
>Category:       lib
>Synopsis:       libedit acts as if no data read if editmode is turned off
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 18 19:35:00 +0000 2011
>Originator:     Steven Vernon
>Release:        sources as of 2011/02/04
>Organization:
Citrix
>Environment:
>Description:
If the terminal is detected as being non-interactive in readline emulation, the 
number of characters read is left as 0 and the el_gets function returns NULL.

The end result of this is that applications think that no data was read.

This can also be encountered if the application deliberately turns off edit 
mode.

>How-To-Repeat:
We got into this case when using Perl expect (*not* expect on the command line) 
talking via SSH to an application using libedit in its readline emulation. 
There are probably simpler use cases.

The bottom line is that libedit should be tested for non-interactive terminals.
>Fix:
In libedit/read.c there is code in FUN(el,gets) that handles the EDIT_DISABLED 
case. This mode is set automatically in readline.c (by doing "el_set(e, 
EL_EDITMODE, 0)") if the terminal is detected as being non-interactive. In this 
case the number of characters read is not updated - the value is stored in 
*nread. This causes the el_gets() routine to return NULL.

If you look earlier in the function, there is a very similar block of code for 
NO_TTY. In that case at the end of the block, it sets the cursor, lastchar, 
*cp, and *nread before going to "done". But the EDIT_DISABLED case does all 
that *except* for setting *nread - this line should be added to the 
EDIT_DISABLED case.