Login shell?

[Griff Smith]

In article <1217 at vsedev.VSE.COM>, logan at vsedev.VSE.COM (James Logan III) writes:
> In article <10791 at ulysses.homer.nj.att.com> ggs at ulysses.homer.nj.att.com (Griff Smith) writes:

[sorry, I've lost track of who owns the following fragment]

> >> ...This will work on any unix system, while the naming convention may not.

[this one's mine]

> >Still not quite right.  I usually use an AT&T 630 terminal on a 4.3BSD
> >system.  ... The kludge I use involves reading the output of ps ...

[Logan's reply]

> What is the purpose?  If you just want to find out what if the current
> shell is indeed the shell spawned by init(1M) (via getty(1M), login(1)),
> then just write a simple C program like this:

[deleted programs that get the process group id]

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

> it will be the PID of the login shell (which would be the parent PID
> when this C program is running).
> 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.

This agrees with my original point: this will not work on all UNIX
systems!  The notion of a session id is not well-defined.  I don't like
the `scan ps output' solution either; it's ugly and non-portable.  I
want a way to identify a process that usually [exists]/[doesn't exist] if a
person is [logged in]/[not logged in] to a terminal.  With windows and
job control shells this is a mess.
-- 
Griff Smith	AT&T (Bell Laboratories), Murray Hill
Phone:		1-201-582-7736
UUCP:		{most AT&T sites}!ulysses!ggs
Internet:	ggs at ulysses.att.com