Please disable flow-control by default

[Jan Van Buggenhout]

Binary package hint: coreutils

Not sure if this is the right package, but I think flow-control (XON/XOFF - ctrl-s/ctrl-q) should be disabled by default. It's easy to hit ctrl-s instead of for example ctrl-a (in screen), and wonder why your shell isn't responding anymore. I doubt many people use it anyway, and those who do can enable it.

[Micah Cowan (micahcowan)]

I second the motion. I, personally, like flow-control, and would want it on; but I remember well back in my earlier days, /apparently/ screwing up my terminl with a simple Ctrl-S (which I usually wouldn't even know I'd typed: it'd be accidental), and trying everything I could think of (except, apparently, Ctrl-Q).

However, this has nothing to do with coreutils (stty can't set what the /defaults/ were before it was called). And having all new terminals have ixon turned off would be the wrong approach. Probably the best thing to do would be to add an explicit stty call in users' .bashrc's; I recommend adding a line "stty -ixon" in /skel/.bashrc.

[Micah Cowan (micahcowan)]

Of course, this approach would mean we'd also need to make the same changes to any interactive shells with rc files, such as zsh, ksh or tcsh.

An alternative approach (since there are those who would miss the feature, and wonder why it wasn't enabled), might be to have some of the major terminal emulators display some sort of status, alerting the user to the fact that the flow has been stopped, and to use the appropriate key to resume processing. The disadvantage to this is that it could be very impractical for some virtual ttys (such as the linux console), and would not apply to people who shelled into Ubuntu using some other term em. It's also a lot more work than fiddling with rc files. :)

[Omari Norman (omari-smileystation)]

Are you sure this is an stty issue? I say that because ctrl-s and ctrl-q toggle flow control in bash, but not in other apps such as emacs. Ctrl-S in emacs brings up incremental search, as it should.

ctrl-s and ctrl-q do toggle flow control in zsh, but they don't have that effect if I issue "unsetopt flow_control".

I think bash is doing the flow control, not the terminal driver. However, doing stty ixon seems to have no effect for me either. Hmm...

[Omari Norman (omari-smileystation)]

Scratch my last comment; zsh's line editor does strange things when it comes to flow control...

http://www.zsh.org/cgi-bin/mla/wilma_hiliter/users/2005/msg01205.html?line=25#hilite

[Micah Cowan (micahcowan)]

The emacs behavior is because emacs specifically disables several terminal escapes, such as flow control and keyboard interupt. To demonstrate, open two terminals. Terminal A will be used to run emacs in console mode. Before running emacs, run the "tty" command in Terminal A, and then use that value (for example, "/dev/pts/0" in a stty command in Terminal B: "stty -a < /dev/pts/0". Then run "emacs -nw" in Terminal A, and run the same stty command again in Terminal B; you'll note that emacs has changed the terminal setup, including disabling of flow control. This makes a good deal of sense, since (a) flow control seems much less useful in a windowed program like Emacs, and (b) Emacs needs the control sequences for its own purposes. :)

[Matthias Klose (doko)]

as mentioned in bug #48880:
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.

[Mika Fischer (zoop)]

Maybe someone should write a spec about this and initiate a discussion?

[Micah Cowan (micahcowan)]

I'm not crazy about setting it when you press enter: it's at least as confusing to people when they're running a program as it is when they're typing a command. If we're going to disable it, I vote for disabling it completely (until the user explicitly enables it with stty, or by removing the appropriate line from their .bashrc). Hm.... however, Matthias' proposed behavior actually seems to be the current behavior of bash on Hardy Heron, so if that _is_ an agreeable solution, we could perhaps close this bug out.

As to writing a spec about it: I don't think that's really appropriate for this sort of solution. To turn off flow control by default for new users, simply adding the line "stty -ixoff -ixon" to /etc/skel/.bashrc would do the trick.

Discussion, however, does seem reasonable.

[Mika Fischer (zoop)]

Micah,

does CTRL-S work for you by default (i.e. search forward through shell history)? It sure doesn't for me. It does not completely block the terminal, either, though. It just consumes the next keypress...

[Micah Cowan (micahcowan)]

As I said, Ctrl-S doesn't currently do anything directly on the
commandline, other than to possibly invoke the search facility.

By default, when a command is actively running (I use

  while true; do echo foo; sleep 1; done

), Ctrl-S does work to pause terminal output, for me at least.

[mp3foley (mp3foley)]

Can confirm this is still the case in Lucid Lynx 10.04. Ctrl-s does not search forward, but does work to stop output of a command like "find /". Adding line "stty -ixon -ixoff" to my .bashrc changed the default behavior so bash forward-search-history would work.

I can see how Ctrl-s would be useful when connecting to a remote server, but it was confusing behavior since the bash man page does not mention it. It is my opinion that most uses would not know about or use the flow control behavior, but would possibly use the bash history search, though even that seems unlikely for newer users.

At the minimum I think the bash man page could be edited to add comments at mention of C-s and C-q that they may not work because of terminal flow control and a note about using the stty command. That is where I first looked to confirm that C-s should be doing a forward search just like in Emacs. Only a google search pointed me to the reason it was not working.

[Janne Snabb (snabb)]

This problem still exists on natty.

IMHO XON/XOFF flow control should be disabled by default. It is a historical relic from times when serial terminals were used. Some terminals were so slow that their input buffer would overflow without flow control, thus the terminals could be configured to send XON/XOFF to the OS to temporarily stop the flow of characters while the display or printer was rendering characters. Better terminals and modems supported hardware flow control signals on the RS-232 serial line, but all of them did not, and some times the flow control pins were not connected.

How many uses slow serial terminals these days? I think the people who use them know how to enable XON/XOFF. For pretty much anyone else this is just a nuisance.

[Matt Day (fjarlq)]

I just solved this issue for my users on my Ubuntu system... my two cents:

1) Complaint was: terminal sessions freezing up once in a blue moon.
     Finally I figured out they had just typoed ^S

2) To fix this I created a script: /usr/local/bin/default-stty
     which I run from /etc/profile and /etc/csh.login

3) I'm surprised there is no standard way to set default tty settings for all users.
     It would be handy if there was some config file for this, e.g. /etc/termios.defaults
     Not sure exactly where it belongs. Does any flavor of Unix have this option?

4) For example, I also want everybody to "stty echok". Just a preference of mine.

5) This is not a bash problem. Really this comes down to an inability to customize
     the TTYDEF_* values in the Linux kernel's sys/ttydefaults.h
     without recompiling the kernel. Maybe it should be a sysctl setting at least?

6) So, this bug should be moved to wherever Linux kernel config feature requests belong.
     Is there such a category in Ubuntu/debian?

[B Bobo (yout-bobo123)]

I'd suggest trolls who are apparently competent enough to use terminals, but who still get confused by flow-control should be told off for embarrassing lack of geek :-)

Seriously, flow-control is a useful feature to have enabled by default regardless of terminal speed. @Matt Day, agreed that the setting in the Linux kernel should be controllable via sysctl interface.

[Jan Van Buggenhout (chipzz)]

@Bobo:
Trolls? I beg you are fucking pardon? If anyone is the troll here it's you. I've been using Linux for a very long time (well over 15 years now), I consider myself a very advanced user, but I have never felt the need for flow-control. I definitely do not have a "lack of geek", and certainly should not be told off. If anyone should be told off it's you.

I can understand this feature is useful to you, but it is not useful and highly confusing for just about everyone else, and that is what should determine the default. If you, as part of the minority, want this feature, then the burden should be on you to turn it on, not the other way around.

[B Bobo (yout-bobo123)]

Sorry you took it so personally. I think you mis-read my comment. My comment as written was for trolls who complain about flow-control without actually understanding it. It was not directed at you, as I assumed you are somebody who understands flow-control. Flow-control is an oft-misunderstood topic. When it came up at Linux World not so long ago, Linus Torvalds closed the consensus discussion as basically there is no point fixing something that isn't broken and anyway the correct place for per-user preferences is at application level. He's right. If it bothers you, it's trivial to fix your application preferences.

[Christopher Yeleighton (giecrilj)]

Per-user preferences are the right place for settings that affect a minority of users. This particular problem affects an overwhelming majority of users and applications and should be solved once and for all; the rest can use their per-user preferences to undo the fix.

[Karthik (hashken)]

Was facing a problem with tmux where the panes just used to freeze up. I finally found today, the problem had nothing to do with tmux and the culprit was flow-control.

This totally unused feature is causing a lot of confusion in the community and unrelated bug reports and support questions are being raised for other applications because of the flow-control problem (Just search for 'tmux pane freeze') and see how many results you get.

I totally agree that this feature should be duabled by default.