24 Jul
2020
24 Jul
'20
2:28 a.m.
From: Paul Riley
I'm struggling however with how C processes the
IO. It seems that when I
type at the console, my typing is immediately echoed to my terminal
window. ... nothing appears on the terminal until I press enter, when
the system displays the whole line of input ... How
can I suppress the original C/Unix echo, and get my output to appear
immediately?
This is not a C issue; it's the Unix I/O system (and specifically, terminal I/O).
Normally, Unix terminal input is done line-at-a-time: i.e. the read() call to
the OS (whether for 1 character, or a large number) doesn't return until an
enire line has been typed, and [Retrurn] has been hit; then the entire line is
available. While it's being buffered by the OS, echoing is done, and rubout
processing is also performed.
One can suppress all this; there's a mode call 'raw' (the normal mode is
sometime labelled 'cooked') which suppresses all that, and just gives one the
characters actually typed, as they are typed. The stty() system call can be
used to turn this on.
See the V6 tty(IV) manual entry for more. stty() is in stty(II).
Noel
24 Jul
24 Jul
4:54 a.m.
New subject: V6 Console IO
Noel,
Thanks for your reply.
I had suspected that the Unix behaviour was responsible, and you've made
that clear with the "line at a time" assertion. I tried removing echo in
STTY, but haven't tried raw.
Paul
*Paul Riley*
Mo: +86 186 8227 8332
Email: paul(a)rileyriot.com
On Fri, 24 Jul 2020 at 10:28, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
From: Paul
Riley
I'm struggling however with how C processes
the IO. It seems that
when I
type at the console, my typing is immediately
echoed to my terminal
window. ... nothing appears on the terminal until I press enter,
when
the system displays the whole line of input ...
How
can I suppress the original C/Unix echo, and get my output to appear
immediately?
This is not a C issue; it's the Unix I/O system (and specifically,
terminal I/O).
Normally, Unix terminal input is done line-at-a-time: i.e. the read() call
to
the OS (whether for 1 character, or a large number) doesn't return until an
enire line has been typed, and [Retrurn] has been hit; then the entire
line is
available. While it's being buffered by the OS, echoing is done, and rubout
processing is also performed.
One can suppress all this; there's a mode call 'raw' (the normal mode is
sometime labelled 'cooked') which suppresses all that, and just gives one
the
characters actually typed, as they are typed. The stty() system call can be
used to turn this on.
See the V6 tty(IV) manual entry for more. stty() is in stty(II).
Noel
4:37 p.m.
New subject: V6 Console IO
On Fri, Jul 24, 2020, at 00:54, Paul Riley wrote:
Noel,
Thanks for your reply.
I had suspected that the Unix behaviour was responsible, and you've
made that clear with the "line at a time" assertion. I tried removing
echo in STTY, but haven't tried raw.
You'll have a hard time exiting your program if you use raw mode - cbreak should be
enough, and in that case ctrl-c will still work [but even in cbreak mode I believe there
is no way to send "EOF".]
5:15 p.m.
New subject: V6 Console IO
On Fri, Jul 24, 2020 at 12:39 PM Random832 <random832(a)fastmail.com> wrote:
On Fri, Jul 24, 2020, at 00:54, Paul Riley wrote:
There is no such thing as cbreak in sixth edition.
http://man.cat-v.org/unix-6th/1/stty
It's raw or cooked. Life is more interesting ;-)
Good luck
Noel,
Thanks for your reply.
I had suspected that the Unix behaviour was responsible, and you've
made that clear with the "line at a time" assertion. I tried removing
echo in STTY, but haven't tried raw.
You'll have a hard time exiting your program if you use raw mode - cbreak
should be enough, and in that case ctrl-c will still work [but even in
cbreak mode I believe there is no way to send "EOF".]
25 Jul
25 Jul
2:45 a.m.
New subject: V6 Console IO
On Fri, Jul 24, 2020, at 13:15, Clem Cole wrote:
On Fri, Jul 24, 2020 at 12:39 PM Random832
<random832(a)fastmail.com> wrote:
my mistake, though that does mean the rest of my point definitely stands: the program will
need to have some other way (either a sequence of characters input or e.g. some amount of
time passing with no input - did v6 have any mechanism like alarm?) to make the program
recognize the end of its input.
You'll have a hard time exiting your program
if you use raw mode -
cbreak should be enough, and in that case ctrl-c will still
work [but
even in cbreak mode I believe there is no way to send "EOF".]
There is no such thing as cbreak in sixth edition.
http://man.cat-v.org/unix-6th/1/stty
It's raw or cooked. Life is more interesting ;-)
24 Jul
24 Jul
2:34 p.m.
New subject: V6 Console IO
On Thu, Jul 23, 2020 at 10:29 PM Noel Chiappa <jnc(a)mercury.lcs.mit.edu wrote:
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*..
...
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'
25 Jul
25 Jul
2:48 a.m.
New subject: V6 Console IO
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(a)ccc.com> wrote:
On Thu, Jul 23, 2020 at 10:29 PM Noel Chiappa <jnc(a)mercury.lcs.mit.edu wrote:
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*..
...
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'
4:02 a.m.
New subject: V6 Console IO
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(a)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(a)ccc.com> wrote:
>
>
> On Thu, Jul 23, 2020 at 10:29 PM Noel Chiappa <jnc(a)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*..
>
>
3:09 p.m.
New subject: V6 Console IO
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(a)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(a)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(a)ccc.com> wrote:
>
>>
>>
>> On Thu, Jul 23, 2020 at 10:29 PM Noel Chiappa <jnc(a)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*..
>>
>>
3:31 p.m.
New subject: V6 Console IO
Wasn't there an issue that v7 atty used stdin and BSD used stdout?
26 Jul
26 Jul
1:08 a.m.
New subject: V6 Console IO
On Sat, Jul 25, 2020, at 11:31, Richard Salz wrote:
Wasn't there an issue that v7 atty used stdin and
BSD used stdout?
v7 uses stdout, but system iii and v use stdin. oddly enough, later research unix appears
to unconditionally open /dev/tty, making the redirection trick entirely unavailable.
27 Jul
27 Jul
9:11 a.m.
New subject: V6 Console IO
Thanks all for the great input. I replaced line editing code for the time
being with a one-liner to get the Unix input, and of course it works ok.
I'll replace this with my own line editor some time later ;)
Paul
*Paul Riley*
On Sun, 26 Jul 2020 at 09:10, Random832 <random832(a)fastmail.com> wrote:
On Sat, Jul 25, 2020, at 11:31, Richard Salz wrote:
Wasn't there an issue that v7 atty used
stdin and BSD used stdout?
v7 uses stdout, but system iii and v use stdin. oddly enough, later
research unix appears to unconditionally open /dev/tty, making the
redirection trick entirely unavailable.
1369
days inactive
1372
days old
11 comments
6 participants
participants (6)
-
Clem Cole -
jnc＠mercury.lcs.mit.edu -
John Cowan -
Paul Riley -
Random832 -
Richard Salz