Re: [TUHS] V6 Console IO

[Clem Cole <clemc@ccc.com>]

[-- Attachment #1: Type: text/plain, Size: 3688 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 7369 bytes --]