[Top][All Lists]

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

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

From: Linda Walsh
Subject: Re: read -ei "y" -p "> " bug(s)
Date: Thu, 19 Jan 2012 17:17:11 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100228 Lightning/0.9 Thunderbird/ Mnenhy/

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

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
loaded, and a limit of 1, telling it to return upon 1 key in the buff, it
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...


Ishtar:law> read -e -i "y" -n 1 -p "here> "
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> read -e -i "y" -n 1 -p "here> "
here> y

Ishtar:law> read -e -i "y" -N 1 -p "here> "
here> k
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> "
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.

reply via email to

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