Control-s should do forward-search-history

Bug #48880 reported by Manuel López-Ibáñez
This bug report is a duplicate of:  Bug #80635: Please disable flow-control by default. Edit Remove
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
bash (Ubuntu)
Confirmed
Undecided
Unassigned
gnome-terminal (Ubuntu)
Confirmed
Wishlist
Unassigned

Bug Description

(Tested only in Breezy. This may work in Dapper.)

In Bash C-r invokes reverse-search-history. Also, pressing C-s is suppossed to invoke forward-search-history. However, it seems there is some strange conflict or bug in bash (or readline) or Ubuntu's setup. There is a workaround [*]:

$ stty -a | fgrep 'stop = '
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
$ stty stop undef
$ stty -a | fgrep 'stop = '
eol2 = <undef>; start = ^Q; stop = <undef>; susp = ^Z; rprnt = ^R; werase = ^W;
Once we've made this change, Control-S then works for using forward-search-history

[*] http://lists.balug.org/pipermail/balug-talk-balug.org/2005-October/003545.html

description: updated
Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

By the way, this works out of the box in Mandriva 2005. Furthermore:

[mandriva]$ stty -a | fgrep 'stop = '
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;

Thus, they are not using this workaround...

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Also, I don't see anything special in Mandriva's /etc/inputrc

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

An user told me that it works on Kubuntu Dapper, so if this is true, we may well close this report.

Revision history for this message
Will Hayworth (whayworth) wrote :

I've confirmed this bug using bash and Dapper with the latest updates.

Changed in bash:
status: Unconfirmed → Needs Info
Revision history for this message
Will Hayworth (whayworth) wrote :

Sorry about that; forgot to change status!

Changed in bash:
status: Needs Info → Confirmed
Revision history for this message
Matthias Klose (doko) wrote :

One solution I would see to achieve this would be to set the stop character when you press enter, and unset it before you display a prompt.

Revision history for this message
Matthias Klose (doko) wrote :

I cannot see any patches for that behaviour in the mandriva patches for bash.

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

This works in Kubuntu Edgy. Can anyone confirm that this works now?

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Still works in Feisty with Konsole. Closing?

Revision history for this message
Stéphane Démurget (stephane-demurget-free) wrote :

still does not work in feisty with gnome-terminal

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

What happens in gnome-terminal when you press control+s ? Perhaps there is some keyboard shortcut already defined in gnome-terminal. In that case, it is an upstream problem of GNOME and you should report it also there.

Revision history for this message
Daniel Hahler (blueyed) wrote :

I can confirm that "Ctrl-S" does not work in gnome-terminal, while it does in Konsole.
In gnome-terminal, it seems to start a "special sequence input" or similar, e.g. pressing Ctrl-S and then "cursor down" results in a "[B".

Changed in gnome-terminal:
status: Unconfirmed → Confirmed
Revision history for this message
Daniel Hahler (blueyed) wrote :

This might be related to bug 80635 ("Please disable flow-control by default") or "flow-control" in general. At least they say there that "ctrl-s" starts flow-control. Unfortunately I don't know what that means.. ^^

Áron Sisak (asisak)
Changed in gnome-terminal:
importance: Undecided → Wishlist
Revision history for this message
Micah Cowan (micahcowan) wrote :

"Ctrl-S" controls the flow... by pausing all output on the terminal (Ctrl-Q is used to resume output).

The output of the stty commands given above actually are not entirely accurate, because bash changes the state of the tty just before, and after, running a command. If you were to run stty against the tty while bash is still reading input via libreadline, you'd see some different results: at a minimum, -icanon instead of icanon. However, it's possible that readline should also be setting -ixon -ixoff (I'd have to look up if it's really supposed to do this), in which case the settings of stop and start should be ignored, and passed through to bash.

You can check the terminal settings when bash is still listening for input instead of running a command (such as stty itself), by obtaining the name of the pseudo-terminal file that bash is running on with the "tty" command, and then running stty against it from a _different_ terminal/shell: "stty -a < /dev/pts/whatever-the-terminal-is".

The fact that "Ctrl-S" followed by "cursor down" results in gnome-terminal eating the initial ESC of ESC [ B, and then inserts the rest of that sequence, even when stty has ^S assigned for "stop", is clearly a bug. However, it may be a separate bug from whether or not readline is setting the terminal properly. If it turns out there are two separate issues, we will need to split this bug report into two.

Revision history for this message
pms (przemyslslaw) wrote :

Thanks! This was actually very irritating.

I'm using C-r very intensively, and there is really a need for C-s there. It seems that for some reason developers continue on keeping C-s for flow control, even though most users would prefer C-s for forward search.

Revision history for this message
Ganton (ganton) wrote :

Only people that don't know that you can use a different key from Ctrl+S to freeze the flow-control... think that this bug is a duplicate of "bug #80635. Please disable flow-control by default".

This bug is *not* a duplicate of "bug #80635. Please disable flow-control by default". This bug, #48880, is about Ctrl+S doing forward-search-history. For example, executing "stty stop ^X" you can use Ctrl+S to forward-search-history and *also* you have flow-control (using Ctrl+X to freeze the flow-control). That's because those bugs are different.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.