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: NonePriority: 5 - Normal
Severity: 2 - MinorStatus: Done
Privacy: PublicAssigned to: None
Originator Email: -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.

Anonymous
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.

Anonymous
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.

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 17 Jun 2017 10:11:36 PM UTCchetStatusInvalid=>Done
    Wed 14 Jun 2017 02:37:36 PM UTCchetStatusNone=>Invalid

    Back to the top


    Powered by Savane 3.1-cleanup1