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

[Linda Walsh]

Chet Ramey wrote:
> On 1/14/12 12:49 AM, Linda Walsh wrote:
>   
> > /* 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...
> >     
>
> Like Greg Wooledge, I wasn't able to reproduce the second issue with
> `read -N 1' (which I assume is actually something like `read -e -N 1'
> from your description.
>
>   
> > 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
> >     
>
> As Greg said, use `read -t 0'.
>
>   
> > 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.
> >     
>
> That's where you have a bad assumption: read -N 1 means to read exactly one
> character from the input.  It doesn't exactly mean to return when there's
> one character loaded into the readline buffer,
----
   That's not what the man page __says__.. it may be what you meant, but it
says that it if readline is being used to *read*, then -a places the 
char into
readline's edit buffer -n/-N both say they exit after reading N chars, but
readline already has 'N' chars ready to be read -- nether -n nor -N say 
that
they will only read from they TTY...

   (Note, I don't regard this as **that** important -- certainly no where
near as important as breaking "-e", ...)

> one character and return when you have at least one character in the
> buffer.  If it didn't mean that, how could we allow the user to erase any
> default intput? 
You wouldn't.
>  If you wanted readline to return immediately if you had
> one or more characters preloaded, why would you call read that way in the
> first place?  It doesn't add or change anything.
>   
You would think so.  I wondered the same myself.  But if you wanted to
allow separate library calls that were 'object oriented', in that they could
interact with and modify the input stream without the program needing to
be changed, it would be a useful feature.  But throwing in OO features when
basic math evaluations (that are certainly not 'simple statements' as the
original POSIX spec required for -e to cause an errexit), maybe isn't the
top of the priority list..... maybe fix the docs to be more clear for now,
and put the intent on a future wishlist?

                                 

> By default, when using readline to obtain the line, we take characters from
> the beginning of the returned line buffer.  If we want one character, we
> take the first one.
>
> If you want to experiment with skipping any pre-inserted text, try changing
> the value initializing `rlind'.  You could use something like
>   
----
   ???rlind?   am confused?  where do I do that?  You mean in the bash
source code?   Eeek!... I was writing in Shell.. .. I'm running out of time
to take on more projects...

>         rlind = deftext && *deftext ? strlen (deftext) : 0;
>
> before the call to edit_line.
>
> Doing that leads to other questions, though.  Say a user hits return when
> a character has been preloaded into the buffer.  Should the code retrieve
> the key the user pressed, or the key in the line buffer?
>   
----
   You do the same thing that you do now... (i.e. the above is already 
an issue).

if I preload a char into the buff, 'say' "a", and the user presses "b", 
and I
specified -n1/-N1 (think it is both, didn't check both in every case).

I get back "a" -- not what the user entered!...

   Now, you can say it shouldn't return immediately,  -- ok fine, but 
is it good let a user press a key that is different and have that key 
ignored?


   As for the other bug/problem...

   I can't reproduce it on cygwin, -- only on linux and only there 
sporadically),  so since it only happens on linux, it must be a linux 
kernel bug (note, this is the reasoning of Eric Blake regarding a 
coreutils bug I found on cygwin; -- not a bug because it's only found in 
cygwin.. must be a cygwin bug! (despite my finding a strong indication 
of the bug in the change notes -- i.e. the behavior in the buggy area 
was overhauled)...

   Anyway, until I find a more repeatable test case, keep on ignoring 
it...(I can reproduce it, but it is usually when I make a mistake in the 
invocation line
which may be part of the problem... ahh... it's editing the line afterwards
no... it has to do with getting some type of error...

>  y

Ishtar:law> read -e -i "y" -n 1 -p "here> "
here>
Ishtar:law>
Ishtar:law> read -e -i "y" -n 1 -p "here> "
here> y

Ishtar:law> read -e -i "y" -n 1 -p "here> "
here> y
Ishtar:law>
Ishtar:law> read -e -i "y" -n 1 -p "here> "
here> y

Ishtar:law>
Ishtar:law> read -e -i "y" -N 1 -p "here> "
here> k
Ishtar:law>
Ishtar:law> k
If 'k' is not a typo you can use command-not-found to lookup the package 
that contains it, like this:
   cnf k
Ishtar:law> ^M^Cad -e -i "y" -N 1 -p "here> "
Ishtar:law>
---
it wasn't until I got an error (the typo), that it went into the
weird mode... and then -- only when I was in 'edit' mode
i.e. after pressing "ESC" in 'vi mode",...

as I use that to re-execute the line... it has happened


Yeah, I think this will do it...

read -e -N 1 -p "here " -i "<CR>        # missing end DQ
^c                                      # control C out
<up-arrow>                              # re-edit line
<end>"<cr>                              #goto end of line, put on " and CR,
---
now if you try to re-edit the line ESC-k, and return, the
return doesn't end the line..

Seems to only happen when you make just about any type of mistake or 
break out
of the normal 'read exit'... likely it skips resetting the term mode or 
something.