bug-bash
[Top][All Lists]
Advanced

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

Re: What exactly does "read -e" do? bind weirdnesses


From: Rocky Bernstein
Subject: Re: What exactly does "read -e" do? bind weirdnesses
Date: Tue, 23 Sep 2008 11:50:33 -0400

On Tue, Sep 23, 2008 at 8:46 AM, Chet Ramey <address@hidden> wrote:
> Rocky Bernstein wrote:
>> Sorry for the delayed reply.
>>
>> As I now understand it, the situation right now seems a bit
>> inconsistent. "read -e" in a script uses emacs bindings by default even
>> if I've entered "set -o emacs" which I note in the following example:
>
> (I'm assuming you mean `set +o emacs'.)

Yes you are correct I meant "set +o emacs". But I added that line just
to be every explicit and to see how it changed read, if at all.
(Answer: none). The program has the same effect if "set +o emacs"
didn't exist.

>
>> #!/usr/bin/env bash
>> set +o emacs
>> while read -e -p 'huh? ' line ; do
>>   echo $line
>> done
>>
>>
>> But the behavior of "bind -p" is to show nothing, and possibly in the
>> future to give an error saying that "line editing" is not on. And this
>> seems inconsistent. In the context of a script, if "bind -p" isn't
>> reporting on what happens in "read -e", then what is it reporting on?
>> And if it is reporting about what happens in "read -e" then should it
>> not also "default" to emacs bindings when asked to print what is in effect?
>
> It's not that complicated. :-)
>
> You turned off line editing with `set +o emacs'.

Yes here I did, but again to be explicit. The more likely situation is
that it isn't specified which means a programmer has to add that extra
inference that there is a default which is relevant to bind but not
read and it is set to "set +o emacs" for bind but not read.

> At this point, bind will
> report an error because editing is not enabled (debatable behavior, but
> it is what it is).  You then invoke `read -e', explicitly asking for
> readline and line editing, and read a line of text.
>
> What would you have it do?

I would have things be more consistent and transparent. I appreciate
that it might take some consideration to figure out how to make it so,
and there are probably a couple ways to do so.

> Line editing is off, disabled with set +o, but
> read has been told to use readline to obtain the user's input. Since
> editing is disabled, readline uses its default behavior: emacs-like key
> bindings.

When you are not in an interactive shell, then the only bindings one
could possibly ever see are via "read -e". Correct? And a read
*without* -e even doesn't turn on, say, emacs editing even if "set -o
emacs" is in effect.

So if this is the case, then when not in an interactive shell "bind
-p" should report what "read -e" reads. Or "read -e" should give the
same warning/error that "Line editing is off" that I am given to
assume "bind -p" will eventually do. These make the bind/read actions
more transparent and consistent.

Finally, given that there is a close relation between what one does in
"bind" and "read" when not in interactive mode, I think this should be
made more explicit in bashref.texi:  when "set -o emacs/vi" has an
effect on read and when it doesn't. Perhaps some examples or perhaps
to give detail in one place and *summarize* along with citing a
reference to another section.

Thanks.




reply via email to

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