bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

read -ei "y" -p "> " bug(s)


From: Linda Walsh
Subject: read -ei "y" -p "> " bug(s)
Date: Fri, 13 Jan 2012 21:49:56 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.24) Gecko/20100228 Lightning/0.9 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666

/* vim: ts=1 sw=1 et sc fo=cqwa1 tw=78 syntax=css */
There's actually 1 parts 2 this, I ran into the 2nd while testing the first...

I wanted to be able to check the keyboard if the user had 'typed' ahead,
and mean to answer an upcoming question on purpose or if it was left over from a previous
y/n single input response.

I wanted to do a
  read -t 0.01 pre_ans

just before my read to see if there was input already available and scarf it up.. initially just to 'flush the buffer', but later with the intent of asking if that was what they meant, and to just accept the type ahead... (didn't want to take a key press accidently doubled as input to a next command, but wanted to allow it
to enable it if that was desired).

I wanted a way to be able to take any key I pre-read in, and put it back into the input
stream if the user wanted it done... I thought to use
the preload feature of readline, and load their key into the buffer if it
was a normal key (I wanted to be able to examine keys outside of the input stream,
basically)...


Well -- it didn't return until the user pressed a key -- so even with a key already loaded, and a limit of 1, telling it to return upon 1 key in the buff, it still
didn't return until it got the 2nd key.

The thing is, if the user presses a key and doesn't erase the key presented, their
key is ignored.

So either 1) it should come back immediately because it already has the one key, or 2,
if the use presses a different key, then it should take that key.


II -- while testing the above, .. found a more annoying bug --

if you use read -N 1,

on future lines that I would 'edit' (in vimode), CR would be entered as input , but would not recognized as 'enter line'... only ^j worked actually execute the line...

The terminal wasn't in 'raw' mode... output was unchanged, just that CR was no longer
taken for entry.   erase and such still worked normally...


I did an output of stty -a of a working window and a non working one, the settings
are the same!

It is repeatable
BASH_VERSION = 4.1.10(1)-release





reply via email to

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