bug-bash
[Top][All Lists]
Advanced

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

Re: Man page description of delete-char, when is EOF returned?


From: Chet Ramey
Subject: Re: Man page description of delete-char, when is EOF returned?
Date: Mon, 06 Jan 2014 11:59:54 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1

On 1/5/14 6:15 PM, Parke wrote:
> Hi,
> 
> From bash's man page:
> 
>    Commands for Changing Text
>        delete-char (C-d)
>               Delete  the character at point.  If point is at the beginning of
>               the line, there are no characters in  the  line,  and  the  last
>               character typed was not bound to delete-char, then return EOF.
> 
> I believe the above does not describe the actual behavior.  Specifically, if:
> 
> 1) I bind C-d to delete-char in ~/.inputrc.
> 2) I press C-d at an empty prompt.
> 3) Then EOF is returned (and bash exits).

It's true, through a combination of imprecise language and a bug in the
code involving the callback interface.

> However in the above case, C-d (the last character typed) *is* bound
> to delete-char, so according to the man page, EOF should *not* be
> returned.

The meaning of `last character typed' is the character before the ^D, not
the ^D itself.

The idea is that if you use ^D to delete a whole bunch of characters on
the line, starting at the beginning and using delete-char to delete
forward, you don't want an extra one to return EOF and end your session.
However, it has not worked this way in some time, with few, if any,
complaints.

> I believe the actual behavior is as follows:
> 
> "If point is at the beginning of the line, there are no characters in
> the line and C-d is typed, then EOF is generated."

This is pretty close to the status quo.

> This behavior has nothing to do with delete-char, nor with what is (or
> is not) bound to delete-char.  Nor does it matter what C-d is bound
> to.  Even if I bind C-d to the macro "foo", bash will still exit if
> the line is empty and C-d is pressed.

It actually has to do with which character is bound to the tty EOF
character.  Unless people change the default, which few do, that is
universally ^D.  It's described along with delete-char for convenience
because both are usually bound to ^D, not for any other reason.

> (Aside: I am trying to imagine a situation in which delete-char is
> running and the last key typed was not bound to delete-char.  Can this
> even happen?)

That's not the intent of the phrase "the last key typed."

> If I am correct and the man page description of delete-char is
> inaccurate, what should change?

Above all, the man page should change to reflect the current readline
behavior.  Then we can discuss whether or not the behavior described in
the man page is worth having, and whether or not this is the right way
to do it.

> 
> 1) The man page
> 2) Bash's C-d/EOF behavior
> 3) Both?
> 
> I'd argue, both, but I realize others may not agree with me.  In my
> case, I am binding C-d to backward-delete-char, and I want to avoid
> bash exiting when I C-d (backward-delete-char) on an empty line.  (I
> will kludge it with IGNOREEOF=10000, but a cleaner solution, or at
> least an accurate man page, would be nicer.)

If you have ^D bound to the tty eof character, I believe that it should
return EOF when you type ^D on an otherwise empty line.  This mimics the
behavior of all standard utilities, and is what people expect.  You can
use IGNOREEOF or change the tty eof character to get around it.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/



reply via email to

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