The new, improved, but still off "Scroll Lock" saga

The PL/I language does not have short-circuit, although most (all current) PL/I compilers will do a short-circuit if & or | is found in the context of an IF. Worst of both worlds, I’m afraid.

Short-circuit is used quite often, in fact, and is distinctly awkard to do without when there is an ELSE branch.

If short-circuiting operators are such an awful thing, why were they included in the Ada programming language? Hmmm, Mr. or Ms. Smarty Pants?

I can confirm that the Linux VGA console does handle scroll-lock specially. I switched to a text console on my GNU/Linux desktop, and
ran cat. (bash keeps the tty in raw mode, and does its own buffering, but when the shell spawns cat, it puts the tty in cooked line-buffered mode, where the OS handles the line buffering. But one of these days GNU cat will probably use readline too… :wink:

Normally, you type a line, and you see it as you type. When you press return, cat reads it from the terminal and prints it again. Pressing ^S or scroll-lock stops typed characters from appearing on the screen. Unlike with software flow control on e.g. a modem line, the characters don’t appear after you turn off scroll lock (by pressing ^q or scroll lock). They’re still in the input buffer, though; Pressing return will give the whole line, including what you typed while scroll-lock was on. (^S and ^Q are of course the xon/xoff software flow control characters.)

One can disable software flow control by running:
stty stop undef
stty start undef

Now, pressing ^S and ^Q had no special effects; The control characters showed up on the input line. However, even with no start and stop character defined, scroll lock had the same effect as before.

Similarly, running
stty -ixon -ixoff
still didn’t stop scroll lock from having the same effect.

BTW, processes writing to the terminal block when scroll-lock is on. According to ps, WCHAN == write_chan. The kernel source code (in drivers/char/n_tty.c) indicates that write_chan will return EAGAIN if the file descriptor for the terminal is in non-blocking mode. (It isn’t by default, so most things will block.)

IIRC, scroll lock has an effect even while the kernel is booting, before init runs.

Anyway, the interesting thing to conclude from all of this is that Linux does not just send a ^s or ^q when you press scroll lock. scroll lock is directly linked to reads/writes from the console blocking.

This behaviour may or may not change a lot or a little in kernel 2.6, since the tty layer has been rewritten, or something like that.


Peter Cordes

The pause key is useful when an x86 PC is booting. The system pauses right where it is, and you can take your time thinking about what’s on the screen, without LILO or GRUB clearing the screen on you. Incidentally, the pause key pauses them, too, since they only use BIOS calls. Pressing any key continues again.