Is there a easy way to disable the cap locks key?

[Aquadementia]

@TriPolar

I don’t know what you’re running, but this is a pretty standard method of scroll control going back before the invention of the PC. It is configurable in some Telnet emulators, but I’ve never heard one that didn’t implement it, and it’s generally OS level functionality so the terminal emulator doesn’t even matter as long as the control codes are passed to the server.

Go into your DOS command prompt, find a very long text file, then enter the command ‘type file.txt’, obviously using the correct file name and extension. If you press Ctl-S, the display will stop scrolling. Any key will restart it, however printable characters will appear in the next line of input.

Ok, I think I know what you’re talking about now.
If I understand, that’s not really about scrolling, that’s “suspending” an active command.
If you’re interested in the output it’s better to pipe it into more or grep then stopping it at a random place. If I’m not interested in the output I’m not in the habit of interfering.

On Linux you can move up or down in the screen memory buffer using shift-pgup or shift-pgdn. I think that’s were the scrolling you’re talking about comes in.

I normally use FreeBSD, which uses the scroll button to do that, so you can also go up/down one line at a time if you want and don’t have to hold the shift key down. (I never thought about it but I wonder if you can just caplock that in Linux :^)

In dos pause/break also works like ctrl-s. So maybe it’s the pause button you are having a problem with. I can’t remember the last time I hit pause before this fooling around just now.

[TriPolar]

@Aquadementia

Ok, I think I know what you’re talking about now.
If I understand, that’s not really about scrolling, that’s “suspending” an active command.
If you’re interested in the output it’s better to pipe it into more or grep then stopping it at a random place. If I’m not interested in the output I’m not in the habit of interfering.

On Linux you can move up or down in the screen memory buffer using shift-pgup or shift-pgdn. I think that’s were the scrolling you’re talking about comes in.

I normally use FreeBSD, which uses the scroll button to do that, so you can also go up/down one line at a time if you want and don’t have to hold the shift key down. (I never thought about it but I wonder if you can just caplock that in Linux :^)

In dos pause/break also works like ctrl-s. So maybe it’s the pause button you are having a problem with. I can’t remember the last time I hit pause before this fooling around just now.

Well all the terminal emulators have big scroll buffers now so unless there’s an enormous amount of output I don’t do any of that anymore, I just use the scroll bar to scan through the text. And I’d forgotten totally about the Pause button since I never used it.

[Doug_K]

@Aquadementia

Ok, I think I know what you’re talking about now.
If I understand, that’s not really about scrolling, that’s “suspending” an active command.
If you’re interested in the output it’s better to pipe it into more or grep then stopping it at a random place. If I’m not interested in the output I’m not in the habit of interfering.

On Linux you can move up or down in the screen memory buffer using shift-pgup or shift-pgdn. I think that’s were the scrolling you’re talking about comes in.

I normally use FreeBSD, which uses the scroll button to do that, so you can also go up/down one line at a time if you want and don’t have to hold the shift key down. (I never thought about it but I wonder if you can just caplock that in Linux :^)

In dos pause/break also works like ctrl-s. So maybe it’s the pause button you are having a problem with. I can’t remember the last time I hit pause before this fooling around just now.

Ctrl-s/scroll lock goes back to a time when there was no more (or less for that matter) or grep or even piping. Output could go to a device (such as the screen) or a file, and with a terminal there was no such thing as screen memory–once it scrolled past it was gone. Scroll lock was a function of the terminal, not the computer–the terminal would not scroll if it scroll lock was on. It would then accept output until the screen was full and then stop accepting output until scroll lock was turned off. The program wasn’t suspended, it was waiting for the device to be accept output again.

[Aquadementia]

@Doug_K

Ctrl-s/scroll lock goes back to a time when there was no more (or less for that matter) or grep or even piping. Output could go to a device (such as the screen) or a file, and with a terminal there was no such thing as screen memory–once it scrolled past it was gone. Scroll lock was a function of the terminal, not the computer–the terminal would not scroll if it scroll lock was on. It would then accept output until the screen was full and then stop accepting output until scroll lock was turned off. The program wasn’t suspended, it was waiting for the device to be accept output again.

Alright. I guess stopping all that mad scrolling text output means something different on a modern computer running Linux then it did on a dumb terminal connected though a 300 baud modem.

But if it’s waiting for the device to start accepting data, how is that not suspended?
Unless the data goes to a memory buffer, which is suspending the output, until the buffer is full. Then what?
Or the output is lost during that time, which I suppose it could be.

[TriPolar]

@Aquadementia

Alright. I guess stopping all that mad scrolling text output means something different on a modern computer running Linux then it did on a dumb terminal connected though a 300 baud modem.

But if it’s waiting for the device to start accepting data, how is that not suspended?
Unless the data goes to a memory buffer, which is suspending the output, until the buffer is full. Then what?
Or the output is lost during that time, which I suppose it could be.

This all started with hardware control of communications, going back to the dark ages when output devices like a teletype couldn’t keep up with the communication rate. Using RS233 as an example, there were several wires (DSR and DTR?) that turned on and off the output. Some time after the introduction of computers the soft controls Ctl-S and Ctl-Q were enabled. But IIRC those control codes could also control the hardware signals in the terminal as well for some devices. On paper terminals there was no need for scroll buffering, just to control the communication rate, but video terminals changed that. Memory was very expensive then, and scroll buffers didn’t exist for a while, so the need to stop and start the output was critical, but not in hardware, the video terminals could usually handle the highest communication rates, it was overscrolling that had to be limited.

[Chronos]

At the very least, I’d like to see more companies follow Apple’s lead and put an icon in a password field whenever the caps lock key is pressed. It’s a common culprit behind mistyped passwords, where you can’t see immediately that the characters produced are not the ones you want.

[Running_with_Scissors]

@Chronos

At the very least, I’d like to see more companies follow Apple’s lead and put an icon in a password field whenever the caps lock key is pressed. It’s a common culprit behind mistyped passwords, where you can’t see immediately that the characters produced are not the ones you want.

The Windows login screen does this as well. It’s more difficult (but possible) to do it on a web page.

[Doug_K]

@Aquadementia

Alright. I guess stopping all that mad scrolling text output means something different on a modern computer running Linux then it did on a dumb terminal connected though a 300 baud modem.

But if it’s waiting for the device to start accepting data, how is that not suspended?
Unless the data goes to a memory buffer, which is suspending the output, until the buffer is full. Then what?
Or the output is lost during that time, which I suppose it could be.

It’s not suspended because the program is still running (even though it may not look like it to the guy sitting in front of the terminal.) It’s going through a loop of send a line to the terminal, the terminal sends an acknowledgement (ACK), then the program sends the next line. But if the terminal sends a negative acknowledgement (NAK), the program sends the same again. There wasn’t any mechanism for the program to just “go to sleep” and wake up when the terminal was ready. The program was still eating up processor time (which could be precious in those days.)

It was possible for the computer to just blindly send data to the terminal and ignore any responses, in which case output would have been lost during that time. But normally it would be like:

Here’s a line. Got it. Here’s the next line. Got it. Here’s the next line. Didn’t get it. Here’s the same line again. Didn’t get it. Here’s the same line again. Got it. Here’s the next line. Got it.

And so on until finished or interrupted.