Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!agate!ziploc!eps
From: eps@toaster.SFSU.EDU (Eric P. Scott)
Newsgroups: comp.sys.next
Subject: Re: shells and 2.0 rlogind (SOLUTION)
Summary: DEBUG is really ENBUG!!!
Message-ID: <1480@toaster.SFSU.EDU>
Date: 11 Apr 91 03:07:51 GMT
References: <14378@helios.TAMU.EDU> <1991Apr10.223326.4021@cs.umn.edu> <14489@helios.TAMU.EDU>
Reply-To: eps@cs.SFSU.EDU (Eric P. Scott)
Organization: San Francisco State University
Lines: 39

First of all, /usr/etc/rlogind doesn't know ANYTHING about shells.

/bin/login does has a check for shell == /bin/csh, but all it
does is enable NTTYDISC (and this code is removed in 4.3-reno,
since it's really unnecessary).  There isn't anything here that
would prevent any particular shell from functioning.

So what's going on?  Well, the culprit is this piece of code in
[ancient version of] rlogind right before it forks to exec
/bin/login:

#ifdef DEBUG
	{
		int tt = open("/dev/tty", O_RDWR);
		if (tt > 0) {
			(void)ioctl(tt, TIOCNOTTY, 0);
			(void)close(tt);
		}
	}
#endif

(the above is not present in 4.3-reno)

Apparently, NeXT compiled rlogind with DEBUG defined.  Why?  I
don't know why.  But this caused /bin/login to be started with no
control terminal.  csh doesn't like this.  csh REALLY doesn't
like this.

To test this theory, I made a copy of rlogind with the "/dev/tty"
(offset 8818 decimal) scribbled over, and changed /etc/inetd.conf
to run that instead.  Not surprisingly, things seemed to work
just fine after that.

Of course, we'd all be happier if rlogin simply went away...

BTW, going back to 1.0 versions is not such a good idea in this
case.

					-=EPS=-