New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with screen, Ctrl-s, and fish #814

Closed
d5ve opened this Issue May 23, 2013 · 12 comments

Comments

Projects
None yet
7 participants
@d5ve

d5ve commented May 23, 2013

I use Ctrl-s as my GNU screen escape key, rather than the default Ctrl-a. This doesn't seem to work when I use fish (2.0 or master) as my shell.

Nothing at all happens when I press Ctrl-s, and whatever I type next just appears in the terminal. For example the screen command to create a new window is "Ctrl-s c", but this just prints the "c" into the terminal.

Under bash I did have to turn off terminal flow control with "stty -ixon" to use Ctrl-s, but this setting doesn't seem to change anything under fish.

@d5ve

This comment has been minimized.

Show comment
Hide comment
@d5ve

d5ve May 23, 2013

More info: Everything works fine if I start a bash shell, then create or attach to a screen session from within that, even though the windows in the screen session are all themselves using fish as the shell.

d5ve commented May 23, 2013

More info: Everything works fine if I start a bash shell, then create or attach to a screen session from within that, even though the windows in the screen session are all themselves using fish as the shell.

@zanchey

This comment has been minimized.

Show comment
Hide comment
@zanchey

zanchey May 24, 2013

Member

I can reproduce this with fish 924b646 and screen 4.00.03jw4.

The problem appears to be that stty -ixon is indeed needed but that the flow control status gets reset every time fish prints the prompt.

A workaround is stty -ixon; screen -e \^Ss.

Member

zanchey commented May 24, 2013

I can reproduce this with fish 924b646 and screen 4.00.03jw4.

The problem appears to be that stty -ixon is indeed needed but that the flow control status gets reset every time fish prints the prompt.

A workaround is stty -ixon; screen -e \^Ss.

@d5ve

This comment has been minimized.

Show comment
Hide comment
@d5ve

d5ve May 24, 2013

That workaround fixed things for me, thanks. I just changed my current alias/function for starting screen to include the stty stuff.
I'm closing this, as it's a pretty edge-case "bug".

d5ve commented May 24, 2013

That workaround fixed things for me, thanks. I just changed my current alias/function for starting screen to include the stty stuff.
I'm closing this, as it's a pretty edge-case "bug".

@d5ve d5ve closed this May 24, 2013

@naggie

This comment has been minimized.

Show comment
Hide comment
@naggie

naggie Jul 30, 2013

I experience this problem. Specifically, I can't turn off flow control like I can with bash using stty -ixon -ixoff so whenever I'm using fish (tmux or not, vim or not) accidentally pressing CTRL+S will lock the terminal.

I assumed this was instability before, until I discovered that CTRL+Q could bring it back. However, I would much rather just turn flow control off.

naggie commented Jul 30, 2013

I experience this problem. Specifically, I can't turn off flow control like I can with bash using stty -ixon -ixoff so whenever I'm using fish (tmux or not, vim or not) accidentally pressing CTRL+S will lock the terminal.

I assumed this was instability before, until I discovered that CTRL+Q could bring it back. However, I would much rather just turn flow control off.

@zanchey

This comment has been minimized.

Show comment
Hide comment
@zanchey

zanchey Jul 31, 2013

Member

Reopening... we really should respect existing terminal modes, especially -ixon -ixoff. I wonder if we should even turn it off by default - is there any good use case for it?

Member

zanchey commented Jul 31, 2013

Reopening... we really should respect existing terminal modes, especially -ixon -ixoff. I wonder if we should even turn it off by default - is there any good use case for it?

@zanchey zanchey reopened this Jul 31, 2013

@naggie

This comment has been minimized.

Show comment
Hide comment
@naggie

naggie Jul 31, 2013

Agreed.

I think it should be turned off by default; because this is an ancient, depreciated 'feature' that is not really used today.Who would use fish over a VT100? Especially as it's not compatible anyway. I think it's more likely to cause confusion and a bad impression of fish if left on.

Whilst other terminals leave it on for compatibility, fish places itself as a modern shell.

If anyone needs to use it, they'll know what it is and how to configure it.

Cheers
Cal

naggie commented Jul 31, 2013

Agreed.

I think it should be turned off by default; because this is an ancient, depreciated 'feature' that is not really used today.Who would use fish over a VT100? Especially as it's not compatible anyway. I think it's more likely to cause confusion and a bad impression of fish if left on.

Whilst other terminals leave it on for compatibility, fish places itself as a modern shell.

If anyone needs to use it, they'll know what it is and how to configure it.

Cheers
Cal

@leeola

This comment has been minimized.

Show comment
Hide comment
@leeola

leeola Aug 16, 2013

I too ran into this, quite annoying when the standard solution of stty -ixon seemingly didn't work in Fish. I thought i had to change shells

leeola commented Aug 16, 2013

I too ran into this, quite annoying when the standard solution of stty -ixon seemingly didn't work in Fish. I thought i had to change shells

@zanchey

This comment has been minimized.

Show comment
Hide comment
@zanchey

zanchey Aug 23, 2013

Member

OK, so the real problem here is that we save the terminal mode when we start a new job, then restore it when it completes. This protects our terminal against accidentally catting a binary file, and similar problems, but it means that stty has exactly zero effect. Not sure what the right solution here is; special-casing stty seems like it could cause problems. Even if we turn XOFF/XON off by default, there should probably be a way to restore it...

Member

zanchey commented Aug 23, 2013

OK, so the real problem here is that we save the terminal mode when we start a new job, then restore it when it completes. This protects our terminal against accidentally catting a binary file, and similar problems, but it means that stty has exactly zero effect. Not sure what the right solution here is; special-casing stty seems like it could cause problems. Even if we turn XOFF/XON off by default, there should probably be a way to restore it...

ridiculousfish added a commit that referenced this issue Sep 23, 2013

@ridiculousfish

This comment has been minimized.

Show comment
Hide comment
@ridiculousfish

ridiculousfish Sep 23, 2013

Member

7ce5f34 disables flow control - let's see if anyone complains. I also don't know what to do about stty.

Thanks for reporting this.

Member

ridiculousfish commented Sep 23, 2013

7ce5f34 disables flow control - let's see if anyone complains. I also don't know what to do about stty.

Thanks for reporting this.

@naggie

This comment has been minimized.

Show comment
Hide comment
@naggie

naggie Sep 23, 2013

Awesome :-) no problem. Thanks for fixing it.
On 23 Sep 2013 02:17, "ridiculousfish" notifications@github.com wrote:

7ce5f347ce5f34 flow control - let's see if anyone complains. I also don't know
what to do about stty.

Thanks for reporting this.


Reply to this email directly or view it on GitHubhttps://github.com//issues/814#issuecomment-24895040
.

naggie commented Sep 23, 2013

Awesome :-) no problem. Thanks for fixing it.
On 23 Sep 2013 02:17, "ridiculousfish" notifications@github.com wrote:

7ce5f347ce5f34 flow control - let's see if anyone complains. I also don't know
what to do about stty.

Thanks for reporting this.


Reply to this email directly or view it on GitHubhttps://github.com//issues/814#issuecomment-24895040
.

@trulyliu

This comment has been minimized.

Show comment
Hide comment
@trulyliu

trulyliu Dec 14, 2016

I swtiched from bash to fish on ubuntu 16.04 recently,
CTRL-S and CTRL-Q does not work as before.
Are there any configuration can be used to flow control on?

trulyliu commented Dec 14, 2016

I swtiched from bash to fish on ubuntu 16.04 recently,
CTRL-S and CTRL-Q does not work as before.
Are there any configuration can be used to flow control on?

@faho

This comment has been minimized.

Show comment
Hide comment
@faho

faho Dec 14, 2016

Member

@trulyliu: Fish disables flow control, i.e. that feature. There currently is no configuration option to reenable it.

If you wish to propose a way to change that, #2315 should be the correct issue to do that.

Member

faho commented Dec 14, 2016

@trulyliu: Fish disables flow control, i.e. that feature. There currently is no configuration option to reenable it.

If you wish to propose a way to change that, #2315 should be the correct issue to do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment