🚀 go-pugleaf

In article <8904061109.AA02168@sun103.cel.uucp> mcvax!cel!dmd@uunet.uu.net 
	(dave driver) writes:
>X-Sun-Spots-Digest: Volume 7, Issue 248, message 7 of 13
>cstw01!meulenbr@uunet.uu.net (Frans Meulenbroeks) writes:
>> Is there a way to detect your login tty?  
>
[..RTFM message deleted..]
>
>setenv LOGTTY `tty`
>...
>RTFOP might be appropriate for this message (OP == "original posting"):
>"ttyname(3) only gives me the name of the pty of the current window or
>rlogin session."...--wnl

Not quite.  Dave is actually right, almost.  He does want the `tty` from the
login terminal, so what Frans needs to add to .login is:

	if ( ! $?LOGTTY ) setenv LOGTTY `tty`

This will set LOGTTY if and ONLY IF it is not currently set (as in a
virgin login session).  It is not required to go through the parent
process proc structures.  Each case of the subshells created through
sunview/suntools will inherit the parent's environment (as they should) in
which case the LOGTTY variable will be set.  Since the setenv LOGTTY is in
the .login it will only be executed when the person logs in (or on a
latter 'source' command), subshells created by suntools/sunview do use
pseudo-ttys, but they do not execute the .login file.  If, of course, he
does an 'rlogin' through the initialization file for suntools then there
is no way that the environment will be set, because he is doing a totally
complete login session, in which case the LOGTTY will be correctly set for
that system.

For those of you sh/ksh hackers, you should add this to .profile:

	if [ ${LOGTTY:-foobar} = foobar ] ; then
		LOGTTY=`tty`
		export LOGTTY
	fi


		-- Gordon.
-- 
Gordon C. Galligher  <|> ...!uunet!telxon!gorpong <|> gorpong@teleng.uucp.uu.net
Telxon Corporation
Akron, Ohio, 44313   
(216) 867-3700 (3512)