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
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
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.
--
You received this bug
@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
** Also affects: linux
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/80635
Title:
Please disable flow-control by default
To manage notifications about
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
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
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
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
** Bug watch added: Debian Bug tracker #383760
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383760
** Also affects: bash (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383760
Importance: Unknown
Status: Unknown
** Changed in: bash (Ubuntu)
Status: New =
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...
--
Please disable flow-control by default
https://bugs.launchpad.net/bugs/80635
You
** Changed in: bash (Debian)
Status: Unknown = New
--
Please disable flow-control by default
https://bugs.launchpad.net/bugs/80635
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
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.
--
Maybe someone should write a spec about this and initiate a discussion?
--
Please disable flow-control by default
https://bugs.launchpad.net/bugs/80635
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
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
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.
--
Please disable flow-control by default
https://bugs.launchpad.net/bugs/80635
You received this bug notification because you
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
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
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
--
Please disable flow-control by default
https://bugs.launchpad.net/bugs/80635
You received this bug
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
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,
21 matches
Mail list logo
