The Unix Heritage Society mailing list
 help / color / Atom feed
* Re: [TUHS] V6 Console IO
@ 2020-07-25 17:45 Noel Chiappa
  0 siblings, 0 replies; 21+ messages in thread
From: Noel Chiappa @ 2020-07-25 17:45 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Clem Cole <clemc@ccc.com>

    > another old V6 trick is the use file redirection from the different
    > terminal to unlock a hosed tty. 

'stty {mumble} > /dev/ttyX', in case that wasn't clear.

Note that this only works if you have a working shell on _another_ terminal,
so if you're e.g. working with an emulation which has only one working
terminal, and your raw-mode program on it has gone berserk, 'See Figure 1'.
It really is advised to have another working terminal if you want to play
with raw-mode programs.

	Noel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-26  1:08           ` Random832
@ 2020-07-27  9:11             ` Paul Riley
  0 siblings, 0 replies; 21+ messages in thread
From: Paul Riley @ 2020-07-27  9:11 UTC (permalink / raw)
  To: Random832; +Cc: TUHS


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

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

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-25 15:31         ` Richard Salz
@ 2020-07-26  1:08           ` Random832
  2020-07-27  9:11             ` Paul Riley
  0 siblings, 1 reply; 21+ messages in thread
From: Random832 @ 2020-07-26  1:08 UTC (permalink / raw)
  To: TUHS

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.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-25 15:09       ` Clem Cole
@ 2020-07-25 15:31         ` Richard Salz
  2020-07-26  1:08           ` Random832
  0 siblings, 1 reply; 21+ messages in thread
From: Richard Salz @ 2020-07-25 15:31 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Noel Chiappa


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

Wasn't there an issue that v7 atty used stdin and BSD used stdout?

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-25  4:02     ` John Cowan
@ 2020-07-25 15:09       ` Clem Cole
  2020-07-25 15:31         ` Richard Salz
  0 siblings, 1 reply; 21+ messages in thread
From: Clem Cole @ 2020-07-25 15:09 UTC (permalink / raw)
  To: John Cowan; +Cc: TUHS main list, Noel Chiappa


[-- 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 --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-25  2:48   ` Paul Riley
@ 2020-07-25  4:02     ` John Cowan
  2020-07-25 15:09       ` Clem Cole
  0 siblings, 1 reply; 21+ messages in thread
From: John Cowan @ 2020-07-25  4:02 UTC (permalink / raw)
  To: Paul Riley; +Cc: TUHS main list, Noel Chiappa


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

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: 6141 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-24 14:34 ` Clem Cole
@ 2020-07-25  2:48   ` Paul Riley
  2020-07-25  4:02     ` John Cowan
  0 siblings, 1 reply; 21+ messages in thread
From: Paul Riley @ 2020-07-25  2:48 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Noel Chiappa


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

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: 5477 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-24 17:15     ` Clem Cole
@ 2020-07-25  2:45       ` Random832
  0 siblings, 0 replies; 21+ messages in thread
From: Random832 @ 2020-07-25  2:45 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS



On Fri, Jul 24, 2020, at 13:15, Clem Cole wrote:
> On Fri, Jul 24, 2020 at 12:39 PM Random832 <random832@fastmail.com> wrote:
> > 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 ;-)

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.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-24 14:36 ` Clem Cole
@ 2020-07-25  1:53   ` Dave Horsfall
  0 siblings, 0 replies; 21+ messages in thread
From: Dave Horsfall @ 2020-07-25  1:53 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society


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

On Fri, 24 Jul 2020, Clem Cole wrote:

>       I pretty much have the V6 kernel memorized, from working with it
>       back in the day... :-)
> 
> Amen bro -- not sure if we should be proud or ashamed of that use of 
> brain cells. 

Add me to that list too; in fact, you'll see my name in the back of the 
Lions book (I helped to proof-read, and arranged its printing).

Mind you, I grabbed so much from V7 that I was known as "Mr Unix 6-1/2" 
(we could not run V7 on our 40-class boxes so I put in what I liked and 
what would fit).

-- Dave

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-24 16:37   ` Random832
@ 2020-07-24 17:15     ` Clem Cole
  2020-07-25  2:45       ` Random832
  0 siblings, 1 reply; 21+ messages in thread
From: Clem Cole @ 2020-07-24 17:15 UTC (permalink / raw)
  To: Random832; +Cc: Grant Taylor via TUHS


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

On Fri, Jul 24, 2020 at 12:39 PM Random832 <random832@fastmail.com> wrote:

> 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".]
>
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

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-24  4:54 ` Paul Riley
@ 2020-07-24 16:37   ` Random832
  2020-07-24 17:15     ` Clem Cole
  0 siblings, 1 reply; 21+ messages in thread
From: Random832 @ 2020-07-24 16:37 UTC (permalink / raw)
  To: Grant Taylor via TUHS

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".]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-24 14:33 Noel Chiappa
@ 2020-07-24 14:36 ` Clem Cole
  2020-07-25  1:53   ` Dave Horsfall
  0 siblings, 1 reply; 21+ messages in thread
From: Clem Cole @ 2020-07-24 14:36 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: TUHS main list


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

On Fri, Jul 24, 2020 at 10:34 AM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

> I pretty much have the V6 kernel memorized, from working with
> it back in the day... :-)
>
Amen bro -- not sure if we should be proud or ashamed of that use of brain
cells.

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-24  2:28 Noel Chiappa
  2020-07-24  4:54 ` Paul Riley
@ 2020-07-24 14:34 ` Clem Cole
  2020-07-25  2:48   ` Paul Riley
  1 sibling, 1 reply; 21+ messages in thread
From: Clem Cole @ 2020-07-24 14:34 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: TUHS main list


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

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: 4020 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
@ 2020-07-24 14:33 Noel Chiappa
  2020-07-24 14:36 ` Clem Cole
  0 siblings, 1 reply; 21+ messages in thread
From: Noel Chiappa @ 2020-07-24 14:33 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Larry McVoy

    > Yeah, write is unbuffered though I think Noel is correct, it's going to
    > a tty and the tty will buffer until \n

The 'wait until newline' is on the input side.

Output is buffered (in the sense that characters are held in the kernel until
the output device can take them); but normally output will start to happen as
soon as the device is able to take them. Only a certain amount can be
buffered though, after that (the 'high water', I think it's called), the
process is blocked if it tries to do output, and awakened when the buffered
output level goes past the 'low water' mark.

Note that getchar() and putchar() are subroutines in a library; looking
at the source:

  https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s4/getchr.s

you can see how they relate to the actual read/write calls to the OS.

    > So you probably have to set the tty in raw mode

Probably best to run such programs from something other than the main console,
because if there's a bug in the program, and the terminal is in raw mode, if
you're on the console, you may have to reboot the system to regain control of
the system. (Interrupt characters, ^D etc won't work.)

    > (sorry that I'm vague, I never ran V6).

Tnat's OK, I pretty much have the V6 kernel memorized, from working with
it back in the day... :-)

	Noel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-24  4:54     ` Paul Riley
@ 2020-07-24 14:01       ` Larry McVoy
  0 siblings, 0 replies; 21+ messages in thread
From: Larry McVoy @ 2020-07-24 14:01 UTC (permalink / raw)
  To: Paul Riley; +Cc: tuhs

Yeah, write is unbuffered though I think Noel is correct, it's going to
a tty and the tty will buffer until \n

So you probably have to set the tty in raw mode (sorry that I'm vague,
I never ran V6).

On Fri, Jul 24, 2020 at 12:54:40PM +0800, Paul Riley wrote:
> Sorry, I see you used "write".
> 
> *Paul Riley*
> 
> 
> 
> On Fri, 24 Jul 2020 at 12:41, Paul Riley <paul@rileyriot.com> wrote:
> 
> > Larry,
> >
> > Thanks for that. The documentation for putchar says that it only puts the
> > low byte of the argument, so I assume that passing an int is ok.
> >
> > Paul
> >
> > *Paul Riley*
> >
> >
> > On Fri, 24 Jul 2020 at 10:57, Larry McVoy <lm@mcvoy.com> wrote:
> >
> >> > int main() {
> >> > int c;
> >> > while ((c = getchar()) != EOF) {
> >> > putchar(c);
> >> > }
> >> > }
> >>
> >> int
> >> main()
> >> {
> >>         int     c;
> >>         char    C;
> >>
> >>         while ((c = getchar()) != EOF) {
> >>                 C = c;
> >>                 write(1, &C, 1);
> >>         }
> >> }
> >>
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-24  4:41   ` Paul Riley
@ 2020-07-24  4:54     ` Paul Riley
  2020-07-24 14:01       ` Larry McVoy
  0 siblings, 1 reply; 21+ messages in thread
From: Paul Riley @ 2020-07-24  4:54 UTC (permalink / raw)
  To: Larry McVoy; +Cc: tuhs


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

Sorry, I see you used "write".

*Paul Riley*



On Fri, 24 Jul 2020 at 12:41, Paul Riley <paul@rileyriot.com> wrote:

> Larry,
>
> Thanks for that. The documentation for putchar says that it only puts the
> low byte of the argument, so I assume that passing an int is ok.
>
> Paul
>
> *Paul Riley*
>
>
> On Fri, 24 Jul 2020 at 10:57, Larry McVoy <lm@mcvoy.com> wrote:
>
>> > int main() {
>> > int c;
>> > while ((c = getchar()) != EOF) {
>> > putchar(c);
>> > }
>> > }
>>
>> int
>> main()
>> {
>>         int     c;
>>         char    C;
>>
>>         while ((c = getchar()) != EOF) {
>>                 C = c;
>>                 write(1, &C, 1);
>>         }
>> }
>>
>

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-24  2:28 Noel Chiappa
@ 2020-07-24  4:54 ` Paul Riley
  2020-07-24 16:37   ` Random832
  2020-07-24 14:34 ` Clem Cole
  1 sibling, 1 reply; 21+ messages in thread
From: Paul Riley @ 2020-07-24  4:54 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs


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

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@rileyriot.com



On Fri, 24 Jul 2020 at 10:28, Noel Chiappa <jnc@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
>

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-24  2:57 ` Larry McVoy
@ 2020-07-24  4:41   ` Paul Riley
  2020-07-24  4:54     ` Paul Riley
  0 siblings, 1 reply; 21+ messages in thread
From: Paul Riley @ 2020-07-24  4:41 UTC (permalink / raw)
  To: Larry McVoy; +Cc: tuhs


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

Larry,

Thanks for that. The documentation for putchar says that it only puts the
low byte of the argument, so I assume that passing an int is ok.

Paul

*Paul Riley*


On Fri, 24 Jul 2020 at 10:57, Larry McVoy <lm@mcvoy.com> wrote:

> > int main() {
> > int c;
> > while ((c = getchar()) != EOF) {
> > putchar(c);
> > }
> > }
>
> int
> main()
> {
>         int     c;
>         char    C;
>
>         while ((c = getchar()) != EOF) {
>                 C = c;
>                 write(1, &C, 1);
>         }
> }
>

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
  2020-07-24  0:18 Paul Riley
@ 2020-07-24  2:57 ` Larry McVoy
  2020-07-24  4:41   ` Paul Riley
  0 siblings, 1 reply; 21+ messages in thread
From: Larry McVoy @ 2020-07-24  2:57 UTC (permalink / raw)
  To: Paul Riley; +Cc: tuhs

> int main() {
> int c;
> while ((c = getchar()) != EOF) {
> putchar(c);
> }
> }

int
main()
{
	int	c;
	char	C;

	while ((c = getchar()) != EOF) {
		C = c;
		write(1, &C, 1);
	}
}

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] V6 Console IO
@ 2020-07-24  2:28 Noel Chiappa
  2020-07-24  4:54 ` Paul Riley
  2020-07-24 14:34 ` Clem Cole
  0 siblings, 2 replies; 21+ messages in thread
From: Noel Chiappa @ 2020-07-24  2:28 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > 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

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] V6 Console IO
@ 2020-07-24  0:18 Paul Riley
  2020-07-24  2:57 ` Larry McVoy
  0 siblings, 1 reply; 21+ messages in thread
From: Paul Riley @ 2020-07-24  0:18 UTC (permalink / raw)
  To: tuhs


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

I am using C in V6 to create a Forth compiler. I don;t have any interest in
Forth as a general purpose language, however I do like it. It's satisfying
to create a language from the ground up. I'm interested in it a simple and
extensible interpreted language for toying with my PDP-11s, so I'll have
some with it in the future.

I have a very basic problem. I am simply using getchar and putchar for
console IO, which is convenient indeed. 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. When I press backspace the system
responds with the character that was deleted, which is fine, as I assume it
was from the paper teletype days. However, my code is receiving input and
also echoing the output, but nothing appears on the terminal until I press
enter, when the system displays the whole line of input, which is
essentially a duplicate of what the terminal originally displayed, but with
the consolidated edits. My code is reading and echoing the input character
by character.

Here's my question. How can I suppress the original C/Unix echo, and get my
output to appear immediately? This simple sample code form the C
programming manual behaves the same.

int main() {
int c;
while ((c = getchar()) != EOF) {
putchar(c);
}
}

Paul



*Paul Riley*

Mo: +86 186 8227 8332
Email: paul@rileyriot.com

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

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, back to index

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-25 17:45 [TUHS] V6 Console IO Noel Chiappa
  -- strict thread matches above, loose matches on Subject: below --
2020-07-24 14:33 Noel Chiappa
2020-07-24 14:36 ` Clem Cole
2020-07-25  1:53   ` Dave Horsfall
2020-07-24  2:28 Noel Chiappa
2020-07-24  4:54 ` Paul Riley
2020-07-24 16:37   ` Random832
2020-07-24 17:15     ` Clem Cole
2020-07-25  2:45       ` Random832
2020-07-24 14:34 ` Clem Cole
2020-07-25  2:48   ` Paul Riley
2020-07-25  4:02     ` John Cowan
2020-07-25 15:09       ` Clem Cole
2020-07-25 15:31         ` Richard Salz
2020-07-26  1:08           ` Random832
2020-07-27  9:11             ` Paul Riley
2020-07-24  0:18 Paul Riley
2020-07-24  2:57 ` Larry McVoy
2020-07-24  4:41   ` Paul Riley
2020-07-24  4:54     ` Paul Riley
2020-07-24 14:01       ` Larry McVoy

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git