Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!comp.vuw.ac.nz!am.dsir.govt.nz!dsiramd!marcamd!mercury!mercury!martin
From: martin@mercury.gen.nz (Martin Kealey)
Newsgroups: comp.unix.xenix.sco
Subject: Re: getty
Message-ID: <1991Jan27.115138.18274@mercury>
Date: 27 Jan 91 11:51:38 GMT
Lines: 43


In a previous message kersing@falken.hobby.nl (Jac Kersing) writes:
>When I set a tty to type unknown in ttytype my login script asks me
>whether I'm using an Ansi terminal (real easy default SCO stuff). This
>works fine when I'm using SCOs getty, BUT when my own version is active
>it somehow doesn't wait for the answer but reacts like I've hit the
>return key immediately.

I've had similar problems to this when I've tried to attach scripts to
terminals to preprocess for getty; the problem also occurs if you try
to use the supplied "more" program. (I haven't tested this, since I
don't have a Xenix system on hand, but I'm pretty sure it's the same
problem)...

Since "more" can have its standard input redirected, it actually *reads*
from stderr! When the standard getty opens the terminal initially to use
as the controlling terminal, it does something like

	open( "/dev/ttyXXX", O_RDWR );
	dup(0);
	dup(0);

which has the effect of having a single filedescriptor for all of stdin,
stdout, and stderr, and which is both readable and writable.  Of course,
there is no way in Bourne Shell to open a file for both read and write
(for stderr you can use "2>file" or "2<file", but using both simply
ignores all but the last.)

So, to replace getty you have to use something like the above code
fragment; a shell script alone *cannot* work.

You can test this for any program like more or tset (presumably what's
in your ~/.profile or ~/.login) under Bourne Shell with

	tset 2</dev/tty
and
	tset 2>/dev/tty

There is no direct equivalent of this for Csh.

Cheers,
Martin.