Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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

share|improve this question
2  
Thank you THANK YOU! :-) –  lzap Nov 20 '12 at 17:12

3 Answers 3

up vote 125 down vote accepted

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.

share|improve this answer
1  
Thank you! BTW, there they suggested Ctrl-C; does it work, too? (And at another place, they suggested Ctrl-Q, just as you.) –  imz -- Ivan Zakharyaschev Apr 27 '11 at 12:41
    
Yes, both Ctrl-C and Ctrl-Q work (at least, for me). –  imz -- Ivan Zakharyaschev Apr 27 '11 at 12:44
9  
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.) –  ak2 Apr 27 '11 at 13:10
    
I see, thanks for the clarification! –  imz -- Ivan Zakharyaschev Apr 27 '11 at 13:28
    
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! –  matchew Apr 9 '13 at 15:40

Press Ctrl+A, it will unfreeze.

share|improve this answer
    
It's like Home usually. Will it work, too? –  imz -- Ivan Zakharyaschev Jul 31 at 9:06
    
I tried it works for me –  Venkatesan Jul 31 at 9:12
    
One-line answers are often not terribly helpful. Consider expanding your answer with documentation that supports your solution (or, at least, logical explanation of what your solution does). –  HalosGhost Jul 31 at 9:29
    
@venkatesan Well, after your comment I went to try it, too: it doesn't work in a terminal where the other two accepted answers work (ctrl-q and ctrl-c). Since I was travelling I onky had a bit unusual terminal at hand: the GNUroot app on an Android device with Debian. The results of my test still make sense: the accepted answer works in this instance of Unix, the new one doesn't. –  imz -- Ivan Zakharyaschev Aug 1 at 16:21

Ctrl-Q is indeed the answer. I thought I'd toss in a little history of this that is too long to fit in the margins of ak2's correct answer.

Back in the dark ages, a terminal was a large piece of equipment that connected to a remote device (originally another terminal because teletypes were so much easier to learn to operate than a telegraph key) over a long wire or via phone lines with modems. By the time Unix was developing, the ASCII code was already well established (although the competing EBCDIC code from IBM was was still a force to be reckoned with).

The earliest terminals kept a printed record of every character received. As long as the character arrived no faster than the print head could type them, at least. But as soon as CRT based terminals were possible, the problem arose that only about 25 lines fit on the CRT, and 25 lines of 80 characters represented enough RAM that no one thought seriously about providing more RAM for characters that had scrolled off the top of the screen.

So some convention was needed to signal that the sending end should pause to let the reader catch up.

The 7-bit ASCII code has 33 code points devoted to control characters (0 to 31 and 127). Some of those had really well established purposes, such as NUL (blank paper tape leader for threading, gaps, and splices), DEL ("crossed out" characters on paper tape indicated by punching all seven holes), BEL (ding!), CR, LF, and TAB. But four were defined explicitly for controlling the terminal device itself (DC1 to DC4 aka Ctrl+Q, Ctrl+R, Ctrl+S and Ctrl+T).

My best guess is that some engineer though that as mnemonics go, "S" for "Stop" and "Q" for "Continue" weren't too bad, and assigned DC3 to mean "please stop sending" and DC1 to mean "ok, continue sending now".

Even that convention was already well established by the time Unix was leaving nest at Bell Labs to go out into the world.

The convention is known as software flow control, and is extremely common in real serial devices. It is not easy to implement correctly, as it prevents the use of either of those characters for any other purpose in the communications channel, and the Stop signal has to be handled ahead of any pending received characters to avoid sending more than the receiving end can handle.

If practical, using additional signals out of band from the serial data stream for flow control is vastly preferred. On directly wired connections that can afford the additional signal wires, you will find hardware handshake in use, which frees up those characters for other uses.

Of course, today's terminal window is not using an actual physical serial port, has scroll bars, and doesn't really need software handshaking at all. But the convention persists.

I recall the claim that Richard Stallman received complaints about his mapping Ctrl+S to incremental-search in the first releases of emacs, and that he was rather unsympathetic to any user that had to depend on a 7-bit, software flow controlled connection.

share|improve this answer
    
Thanke.. very interesting... I've been wondering: Why on earth would anyone choose to Continue a process with "Q" which is commonly used (now) for Quit... The QRST grouping explains it ..... –  Peter.O Apr 27 '11 at 22:40
4  
Thanks very much for that bit of history. I recently disabled flow control by default in a terminal emulator I maintain, but had to reinstate it rather quickly after vocal protests from Unix traditionalists who do still use it. I set the ixany bit instead, so at least people who press ^S without knowing about ^Q don't get stuck. –  ak2 Apr 27 '11 at 22:45
1  
@RBerteig I ran into something similar learning about backspace and delete. Backspace is officially ^H and delete is ^? Some people like the Emacs developers (Stallman again?) wanted ^H available for general purpose like shortcuts like Help. The escape sequence ^[[3~ or something like that was created to replace ^? and backspace now became the old delete character ^?. In fact, I've seen ncurses specifically patched on Linux distros to remap thoses keys in terminfo whereas ncurses on FreeBSD is unpatched causing some of the annoying confusion causing backspace to not work. –  penguin359 Apr 28 '11 at 10:48
2  
I used to wonder why DEL had the code 127 rather than being grouped with the other control characters, until I first played with some paper tape and an ASR33. Once I realized that it had the effect of punching all the holes, which meant it could be overstruck on any previously punched character to delete it, it made sense. –  RBerteig Apr 28 '11 at 19:08
1  
@Mystere Your right, it's not an ANSI Escape sequence, but an ANSI Control Sequence. Escape (^[) followed by [ is an Escape sequence that represents the CSI ANSI Control charater. CSI starts an ANSI Control sequence. The DEC Terminals as far as I can tell never used ^[[3~ for Delete, I think that was added in XTerm. –  penguin359 Apr 28 '11 at 20:40

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.