BTW: another old V6 trick is the use file redirection from the different terminal to unlock a hosed tty. Programming on the console was fraught with multiple dragons and not recommended. But due to program crashes that left things in raw mode, I admit that I remember having to uses the redirection trick a few times to get the console back. As Noel said, it could get dicey if the console ended up with canonicalization turned off. V7's ½ cooked (a.k.a. CBREAK) was a welcomed edition, but the fact is V6's try handler was good enough most needs and a lot of used it pretty successfully for a long time.

Clem

On Sat, Jul 25, 2020 at 12:02 AM John Cowan <cowan@ccil.org> wrote:

Ctrl+J actually is the keystroke for U+000D LINE FEED, so it always works; old-timers got in the habit of typing ^Jreset^J.

Note that if a program gets stuck in rare mode rather than raw mode, you can get out of it with ^C (or whatever INTR is set to), a good reason for using rare mode.

On Fri, Jul 24, 2020 at 10:49 PM Paul Riley <paul@rileyriot.com> wrote:
Yep already fallen into that trap. Glad I'm running on a sim! Yes I'd considered writing a small program to reset the STTY settings, and you've helped me to understand how I can run it!

In answer to the CR question, is it that in raw mode, the CR does not get mapped to LF, and therefore the shell doesn't see the LF character and recognize the end of the line? Incidentally, why the ^J before ft? Just to clean up the shell input status?

I'll write my own ft, thanks. I'll try raw mode, because I want some better line editing capability.

Alternatively if I toy around with /dev/tty does that interfere with the operation of the standard console outside of my app?

Paul

Paul Riley

On Fri, 24 Jul 2020 at 22:36, Clem Cole <clemc@ccc.com> wrote:

On Thu, Jul 23, 2020 at 10:29 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
...
This is not a C issue; it's the Unix I/O system (and specifically, terminal I/O).

...
One can suppress all this; there's a mode call 'raw'
Just be sure to turn raw mode off so canonization is performed again after your program stops running. Remember this a 'system wide' settings for that try and all programs start to use that setting. So if some reason, your program stops and a new program (like the shell) takes back over input from the try, if you do not have a way to get it back you are screwed.

Back in the day, I have a shell script in my path stored in ~/.bin called: ft (fix tty) which called the stty command with the way I wanted the terminal to be set up. Thus is I was running a program that core dumped and left the try in raw mode, if I could find a way to run the ft script (usually by typing ^Jft^J ) life was good again. Paul, as an exercise why would ft<CR> not be good enough? (hint read and study the section 4 man page for stty)

FWIW: is how the original UCB ex/vi and Cornell's Fred editors for v6 works by the way. I suspect that iyou look at any of the video editors of the day it will show you the details.

One of the differences between V7 and earlier UNIX tty handlers was that they tty canonization was split into multiple parts. Also the other hint with Sixthedition's version of raw and cooked modes, you get all or nothing so you if you turn on raw, your program, will have do things like backspace processing, etc..