Control-s should do forward-search-history

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

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


description: updated

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

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

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

Will Hayworth (whayworth) wrote :

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

Changed in bash:
status: Unconfirmed → Needs Info
Will Hayworth (whayworth) wrote :

Sorry about that; forgot to change status!

Changed in bash:
status: Needs Info → Confirmed
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.

Matthias Klose (doko) wrote :

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

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

Still works in Feisty with Konsole. Closing?

still does not work in feisty with gnome-terminal

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.

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
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) on 2007-06-15
Changed in gnome-terminal:
importance: Undecided → Wishlist
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.

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.

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  Edit
Everyone can see this information.

Other bug subscribers