> From: tsarna@endicor.com (Ty Sarna)
> Date: Fri, 19 Apr 1996 04:23:00 GMT

> % Actions to be performed at login and logout time would be controlled
> % by two files: /etc/tty_login and /etc/tty_logout respectively.  Both
> 
> I'd really rather have it all in one file. See below.
Hmmm...  I'm not sure I like that as well...

> % The format could (optionally) be extended to allow multi-line
> % commands by continuing onto the next line when a backslash is
> % the last character on the line.  [ Is this desirable? ]
> 
> Yes. I hate that sup won't let me split long lines, and it seems likely
> that lines in this file might be long.
Sure. Easy enough, and doesn't really hurt anybody.

> % The tty_name would be matched against the name of the current
> % tty line so all lines (and only those lines) with he tty_name
> % field matching would be processed.
> 
> I like cgd's idea about supporting globs here.
OK, let's see what the consensus becomes.

> % The shell_command field would be run as 'sh -c "shell_command"'
> % with the following environment variable guaranteed to be set:
> % 
> % 	USER=user_name
> 
> Also need GROUP for the user's group name.
> Might be nice to have TTY as the login tty's name.

Agreed on TTY="tty_name" but why does anyone need GROUP in
the environment?  After a new login, the tty and all related
devices should be owned by the user, group=tty, and mode=0600.
They own all the devices at that point, so they can change the
group and modes however they please.  I say let the user do it.

> % Example /etc/tty_login file:
> % 	# This line just needs one related device chown'ed
> % 	/dev/wsconsole		chown ${USER} /dev/wsmouse
> % 	# This line has several related devices, which are
> % 	# handled by the external program /etc/console.sh
> % 	/dev/kdconsole		/etc/console.sh login
> 
> To get this all in one file (/etc is cluttered enough, and I'd rather
> not to have to consult two different files to see what's configured for
> a single tty), I propose that a second field be added for the action
> name (like my earlier proposal). Let it be glob matched as well,
> and add ACTION to the environment too. Example:
> 
> # This line just needs one related device chown'ed
> /dev/wsconsole	login	chown ${USER} /dev/wsmouse
> /dev/wsconsole	logout	chown root /dev/wsmouse
> # This line has several related devices, which are
> # handled by the external program /etc/console.sh
> /dev/kdconsole	*	/etc/console.sh ${ACTION}

I thought about something like the "action" field, but I think
the tty_login and tty_logout files are more intuitive in their
similarity to .login and .logout (as well as being simpler).

> % Here is a proposed interface for the new libutil function:
> % 
> % void tty_relatives(char *filepath, char *ttyname, char *username);
> 
> int tty_relatives(char *ttyname, char *action, char *username, char *groupname);
> 
> Returns the return value of the sh -c (can be ignored, but
> the return should be availible).
OK.

> I repeat my earlier question: Should this file (and the rest of libutil)
> have a header? Currently each program that wants libutil stuff declares
> its own prototypes.

Sure, a header would be nice.

> Also, my proposal had the following advantages, though I don't think
> they're significant:
> 
> - fbtab backward compatible (doesn't seem hat important)

Nobody seems to care about that.

> - common actions (chmod, chown) don't require spawning a new process
>   (but logins don't happen that often, so the overhead doesn't seem that
>   critical).

Yeah, the system() (fork/exec) work only happens at login/logout,
and only when there are tty_login or tty_logout records matching
the line you are using.  Not worth worrying about.

> The advantages that are important is a way easily to do things
> with the user's group, and the ability to specify login and logout
> actions together for maintainability.  OTOH, this proposal is simpler
> and cleaner.  So, I propose the above changes to Gordon's proposal as a
> compromise (actually, I think I like it better). Is this agreeable?

How is it useful to "do things with the user's group"?
What would you do that the usr could not do just as well?

How do you justify the additional complexity of the "action" field?
(You might avoid forking a shell, but is that a big deal?)

Gordon