How to unfreeze after accidentally pressing Ctrl-S in a terminal?

  • It's a situation that has happened quite often to me: after I press (with a different intention) Ctrl-S in a terminal, the interaction (input or output) with it is frozen. It's probably a kind of "scroll lock" or whatever.

    How do I unfreeze the terminal after this?

    (This time, I have been working with apt-shell inside a bash inside urxvt--not sure which of them is responsible for the special handling of Ctrl-S: I was searching the history of commands backwards with C-r, as usual for readline, but then I wanted to go "back" forwards through the history with the usual--at least in Emacs--C-s (1, 2, 3), but that caused the terminal to freeze. Well, scrolling/paging to view past things still works in the terminal, but no interaction with the processes run there.)

    I was working in `vim` and I pressed Ctrl-S to save my edits. Uh-oh `XD`

    Why does that exist in first place?

  • ak2

    ak2 Correct answer

    10 years ago

    Ctrl-Q

    To disable this altogether, stick stty -ixon in a startup script. To allow any key to get things flowing again, use stty ixany.

    ps: It's neither the terminal nor the shell that does this, but the OS's terminal driver.

    Thank you! BTW, there they suggested `Ctrl-C`; does it work, too? (And at another place, they suggested `Ctrl-Q`, just as you.)

    Yes, both `Ctrl-C` and `Ctrl-Q` work (at least, for me).

    Ctrl-C does work, but it also sends an interrupt signal, which one generally wouldn't want. (Btw, the keys being used for these things are all configurable through `stty`.)

    Wow, I am so happy to stumble upon this. tabs would freeze a lot for me in urxvt. I guess because I hit ctrl+s by mistake. I use ctrl+a,ctrl+e,and ctrl+o a lot. Thanks!

    I remember trying out this combination on my Apple ][ clone, and it worked there too - `Ctrl-S` and then `Ctrl-Q` to resume.

    Interestingly, when an Emacs is running in the terminal, C-s doesn't freeze it. So, this means that Emacs changes this driver setting and then restores it on exit (or lets it be restored somehow automatically). So sometimes this setting seems to be under an intentional control of a program running in the terminal (which could be the shell or Emacs).

    THANK GOD !! This has been something bugging me for years. Not sure why VIM just hasn't implemented this as a native shortcut for save instead of whatever the hell it does. Good to know there is an escape from the prison which is the frozen VIM screen due to natural use of CTRL+S (save shortcut) that is applicable in nearly all applications EXCEPT VIM.

    @SanuelJackson Ctrl-S "save shortcut" is applicable in nearly all DESKTOP application EXCEPT vim. And Except Emacs. And Nano. And every other "application" you can run on a terminal, exactly because it's already used by the terminal for flow control. It's the same reason you won't find a Linux Desktop application using the Ctrl-Alt-FN shortcuts: because they're already used by the system.

    @SamuelJackson `:w` is much powerer than a C-s shortcut. You can use it to save to a different command, to pipe the buffer's contents to a program or to write to a different file - all of which can't happen with just a shortcut.

    @SamuelJackson there is nothing stopping you from binding ctrl-s to :w command in your .vimrc, see here for example: http://stackoverflow.com/a/11298171/2380702

    On ubuntu 16.04, running stty -ixon disable the freeze effect of ctrl-s, and replaces it with something like "i-search", another feature I don't need at all. As I use emacs shortcuts a lot at my prompt and also switch keyboards up often, I end up hitting ctrl-s by mistake many times a day. Is there any way to let it do nothing at all? (using gnome-terminal btw)

    @ak2 Wow.. you solved a childhood problem.. Bu why does ctrl-S only freezes in cmd line mode and not in GUI mode?

    For MSYS2 use `Ctrl-Z`. Neither `Ctrl-C` or `Ctrl-Q` work

    Be aware that `reset` command will also enable flow control, so you'll need to issue `stty -ixon` again.

    If you put this in your `.profile`, it causes a popup error to appear on login hat reads: "inappropriate ioctl for device" in Ubuntu 17.10: https://askubuntu.com/questions/918169/error-found-while-loading-home-username-profile/970634#970634

    @KraangPrime I remember starting off using Nano/pico — even worse: `CTRL+X y`

    What sort of startup script, for the shell, e.g. `~/.bashrc`?

    Note that when you are searching command with `CTRL-R`, the side effect of `stty -ixon` is that you can also do revert search using the mentioned `CTRL-S`, which is very handy, if you keep pushing `CTRL-R` too fast :)

    I added `stty -ixon` to `~/.bashrc`, then restarted emacs daemon, tmux sessions (a true logout login cycle), then it worked

    Using Emacs through GNU Screen might also disable ctrl-s and ctrl-x-s for search and save-file, which of course is very annoying when it happens. I can keep Emacs sessions for weeks and months otherwise. To make Emacs see ctrl-s again I found `ctrl-a` `f` which toogles the current GNU-Screen "window" between three states: `-flow(auto)`, `-flow` and `+flow` where `+flow` shouldn't be used. (Ctrl-a is the default GNU Screen key, could be different on other setups)

    @gerlos The reason Ctrl S works fine in every desktop application and causes such a mess on Linux (possibly other Unixes) is because of people like you who defend algorithms used 40 years ago when modern computers were invented and output was on a paper instead of a screen. Ctrl S/Q should have been removed 30 years ago and it's a shame such code still dwells in the heart of every linux server.

    @John sorry, I wasn't "defending" anything, just pointing out that exist different ecosystems (terminals, desktops, etc) with different interaction patterns. These ecosystems work they way they work for both historical and practical reasons that are still valid today. I understand that it can be annoying if you're not used to it. But thinking that there should be just one way of doing anything regardless of the context is plainly wrong.

    @gerlos Which partical reason would you provide for this 'feature' to be part of the linux kernel and exposed to tens of millions of users every day ? historic reasons are not a reason to keep a horrible 'feature' alive, they are reason to remove.

    @John You use Ctrl-s (and Ctrl-Q) to pause (and resume) long output scrolling on terminals so you can read what's going on. That's it. It's true, you can use pagers like less or more, but only if you expect a long output coming in, if terminals support them, and if the system can run them (it might not be possible in some emergency situations). Moreover, some (hw and sw) terminals doesn't even support scrolling, so you can't scroll bak to read (serial consoles are often used on embedded devices). So please stop complaining about something you never used and don't understand.

License under CC-BY-SA with attribution


Content dated before 6/26/2020 9:53 AM