Path: utzoo!attcan!uunet!husc6!bbn!gatech!ulysses!ggs
From: ggs@ulysses.homer.nj.att.com (Griff Smith)
Newsgroups: comp.unix.questions
Subject: Re: Login shell?
Summary: one more try: V != 4.3
Message-ID: <10825@ulysses.homer.nj.att.com>
Date: 8 Nov 88 16:56:51 GMT
References: <3ed799bc.103e8@hi-csc.UUCP> <13851@mimsy.UUCP> <511@imec.UUCP> <1229@vsedev.VSE.COM>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 84

In article <1229@vsedev.VSE.COM>, logan@vsedev.VSE.COM (James Logan III) writes:
> My apologies.  I use ksh and it does not reset the process group ID.

Right, your system doesn't have job control.  Wait until Vr4.

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

This is getting strange.  Your responses seem appropriate for
a sheltered member of AT&T who hasn't been allowed near `the
wrong choice'; and I'm the one from AT&T.  One more time: BSD
does not have getutline!  When I read your suggestion, my first
step was to try "nm /lib/libc.a | egrep getu"; the response was

getuid.o:
00000008 T _getuid
getusershell.o:
00000000 T _getusershell

I then tried the same thing on our System V 3B2/600 sitting back in the corner
doing nothing.  The pertinent output was:

Symbols from /lib/libc.a[getut.o]:
getut.c             |        | file |                  |      |     |
getutent            |       0|extern|        *struct( )|   238|     |.text
getutid             |     238|extern|        *struct( )|   155|     |.text
getutline           |     394|extern|        *struct( )|    87|     |.text
getusa              |    1442|static|               ( )|   154|     |.text

I used

> >man getutline
> >No manual entry for getutline.

as a convenient summary that `there ain't no such animal' on the
machine I use.

> >this will not work on all UNIX systems!
> 
> You WILL find this call on ALL System V machines that conform to
> the SVID.

I didn't say it was a System V machine that conforms to the SVID!
I said it was a UNIX system.

> 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 utmp definition in /usr/include/utmp.h on my 4.3BSD tahoe system is:

struct utmp {
	char	ut_line[8];		/* tty name */
	char	ut_name[8];		/* user id */
	char	ut_host[16];		/* host name, if remote */
	long	ut_time;		/* time on */
};

I don't see an entry for ut_pid!  I do see one on my System V machine.

Our local copy of "who" does manage to separate the real tty and the
associated windows:

ggs      tty11   Nov  8 08:51	(windows: ttyp[234] )

Note, however, that I still don't have the pid of the shell connected
to tty11.

I repeat my point: genetic drift has made it dangerous to state that
X works on all UNIX systems.  Perhaps things will get better when
Xenix, System V, Sun release whatever and 4.3BSD get all mushed together
into System V Release 4.

> -- 
> Jim Logan		logan@vsedev.vse.com
> (703) 892-0002		uucp:	..!uunet!vsedev!logan
> 			inet:	logan%vsedev.vse.com@uunet.uu.net
-- 
Griff Smith	AT&T (Bell Laboratories), Murray Hill
Phone:		1-201-582-7736
UUCP:		{most AT&T sites}!ulysses!ggs
Internet:	ggs@ulysses.att.com