Path: utzoo!utgpu!attcan!uunet!vsedev!logan
From: logan@vsedev.VSE.COM (James Logan III)
Newsgroups: comp.unix.questions
Subject: Re: Login shell?
Message-ID: <1229@vsedev.VSE.COM>
Date: 7 Nov 88 19:53:42 GMT
References: <3ed799bc.103e8@hi-csc.UUCP> <13851@mimsy.UUCP> <511@imec.UUCP> <1217@vsedev.VSE.COM> <10808@ulysses.homer.nj.att.com>
Reply-To: logan@vsedev.VSE.COM (James Logan III)
Organization: VSE Software Development Lab
Lines: 54

In article <10808@ulysses.homer.nj.att.com> ggs@ulysses.homer.nj.att.com
(Griff Smith) writes:
>
>In article <1217@vsedev.VSE.COM>, logan@vsedev.VSE.COM (James Logan III)
>writes:
>> Unless you have a program that explicitly resets the process group ID,
>
>I do.  It's called ksh.  The reset is needed to support job control.

My apologies.  I use ksh and it does not reset the process group ID.
I guess you'll have to use the getutline(3C) entry that I mentioned.
(I know, I know -- you can't pull it up with man(1).  Read on.)

>> Another more accurate way to do this is to use getutline(3C) to
>> get a utmp structure for your current tty (which won't work with
>> a multiplexed terminal using sxt's...) and check the parent PID
>> against utmp.ut_pid.  Let me know if you need more details.
>
>man getutline
>No manual entry for getutline.

You're right, you wouldn't find it that way unless you looked in
the manual under "getut".  I figured you would see that
"getutline" was listed under "getut", but since you didn't look
in the manual you wouldn't have seen it.

(That is one BIG reason I try not to use man(1).  I can't pull up
some library calls because they are listed under other calls that
I can never think of unless I see the manual's index.)

>this will not work on all UNIX systems!

You WILL find this call on ALL System V machines that conform to
the SVID.  If your machine doesn't have it, then look up utmp(4)
and write a 10-line function that will read in the structure
declared there and in /usr/include/utmp.h.  I'm pretty sure that
even BSD machines have this.  Even with job control, your utmp
entry's ut_pid WILL be that of your ksh!    

>The notion of a session id is not well-defined.

I agree.  There are all sorts of problems when the device you are
using for I/O is not the device you logged in under.  A program
that looks at the idle time of a terminal and logs you off when
the last atime or mtime of your tty is over a certain limit will
log you off in such a situation, even if you're in the middle of
typing.  That is a pain when I want to use the sxt devices.

			-Jim

-- 
Jim Logan		logan@vsedev.vse.com
(703) 892-0002		uucp:	..!uunet!vsedev!logan
			inet:	logan%vsedev.vse.com@uunet.uu.net