helpThe GNU Bourne-Again SHell - Support: sr #109329, bind -r on unbound sequences...


sr #109329: bind -r on unbound sequences should be a no-op, but it isn't

Submitted by:  None
Submitted on:  Sat 10 Jun 2017 10:57:27 PM UTC  
Category:  None Priority:  5 - Normal
Severity:  2 - Minor Status:  Done
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  None

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Sat 17 Jun 2017 10:11:36 PM UTC, comment #5:

OK. If you think that is a problem worth solving, I would be glad to look at a patch you send to do it. Right now, I don't think it's a big enough problem -- since no characters are ever lost -- to expend the resources and new functions to implement it.

Chet Ramey <chet>
Project Administrator
Thu 15 Jun 2017 10:40:16 AM UTC, comment #4:

That would be a first step, but wouldn't fix the bug completely. It should be possible to unbind multi-key sequences without leaving any residues. So if I bind ^B^S and ^B^B, and then unbind both again, ^B shouldn't wait anymore for another key.

Wed 14 Jun 2017 06:51:51 PM UTC, comment #3:

I can see verifying that the keyseq is bound to something before unbinding it to avoid the confusion.

Chet Ramey <chet>
Project Administrator
Wed 14 Jun 2017 05:38:04 PM UTC, comment #2:

The manual page for bind says "-r keyseq Remove any current binding for keyseq." It does not say that something will be bound to a null function. The expected behavior for bind -r is that is undoes what bind did. It should be possible to eliminate multi-key sequences without leaving any residues, and removing unbound key sequences should not have any effect.

Wed 14 Jun 2017 02:37:36 PM UTC, comment #1:

What you've done is to cause the key sequence "test" to be bound to a null function (removing any previous binding). This means that you've created a set of bindings for "tes" so that you can be sure the final "t" is unbound. The result is that "tes" is now ambiguous: readline has to wait for enough input to ensure which binding is wanted.

Chet Ramey <chet>
Project Administrator
Sat 10 Jun 2017 10:57:27 PM UTC, original submission:

When I enter "bind -r test" and then type test, characters only start to appear after it's fully typed. Characters should start to appear immediately. Sometimes, t appears after it's typed, but only after a small delay. Further, if I type t and before it appears Ctrl+C, bash doesn't go to the next line.



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by chet (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-06-17 chet StatusInvalid => Done
    2017-06-14 chet StatusNone => Invalid

    Back to the top

    Powered by Savane 3.4