[ I forgot to change the subject last time. -gwr ]

> Cc: matt@ibmoto.com, perry@piermont.com, carrel@cisco.com,
>         current-users@netbsd.org
> Date: Thu, 18 Apr 1996 20:01:27 -0400
> From: Chris G Demetriou <Chris_G_Demetriou@UX2.SP.CS.CMU.EDU>

[...]
> > The shell_command field would be run as 'sh -c "shell_command"'
> > with the following environment variable guaranteed to be set:
> > 
> > 	USER=user_name
> 
> I would say that you also want the name of the tty that they're
> logging in to or out of...  That way i could write one big program,
> that handled all of the actions for all of my ttys, rather than having
> to have lots of little scripts...

I think you have that ability with the proposed interface.
Here is an example of how it might be done:

	# One program does the job for every line.
	/dev/console	/etc/all_in_one /dev/console
	/dev/ttyfoo	/etc/all_in_one /dev/ttyfoo
	/dev/xyzzy	/etc/all_in_one /dev/xyzzy

> a default path would be nice, too...  8-)

OK, the normal system default path can be added.

> > This format allows simple commands to be specified directly as
> > a shell command, and more complicated processing could be done
> > with an external program.  Here are examples of each:
> > 
> > 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
> >
> > Example /etc/tty_logout file:
> > 	# This line just needs one related device chown'ed
> > 	/dev/wsconsole		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 logout
> 
> I would suggest that the tty names as used in these files be the same
> as those in /etc/ttys, unless there's a good reason to do otherwise.

That was exactly my intention.  The names wsconsole and kdconsole
are simply hypothetical names of what would be real tty lines
listed in /etc/ttys with exactly those names.

Sorry if that was not clear...

> > Here is a proposed interface for the new libutil function:
> > 
> > void tty_relatives(char *filepath, char *ttyname, char *username);
> > 
> > 	filepath: one of:
> > 		_PATH_TTY_LOGIN 	("/etc/tty_login")
> > 		_PATH_TTY_LOGOUT 	("/etc/tty_logout")
> > 	
> > 	ttyname:  name of the tty getty runs on (i.e. /dev/console)
> 
> again, why not as specified in /etc/ttys?

Now I'm not sure I follow you.  The ttyname WOULD be as specified
in the /etc/ttys file (that is what I indended anyway).

> > The above function would be called by src/usr.bin/login/login.c
> > just after it does the chown call to the tty line, i.e.:
> > 
> > 	tty_relatives(_PATH_TTY_LOGIN, ttyn, pwd->pw_name);
> > 
> > The same function would also be called by getty in main.c as:
> > 
> > 	tty_relatives(_PATH_TTY_LOGOUT, ttyn, "root");
> > 
> > just after it does its chown/chmod calls for the tty line.
> 
> This looks sane, to me...
> 
> > There may be better ways to communicate the various pieces of
> > information like $USER in the call to tty_relatives(), and the
> > name of that function is certainly open to improvments...
> 
> I see you're as good at naming functions as I am...  8-)

Yeah.  I'd rather leave names to people who care more about such
things than I do (which is a large class of people! 8^)

> One possible adjustment: it may make sense to have the 'matching' code
> support wildcards, either via glob-like syntax or regexps...
> 
> For instance, i can imagine wanting to do something like:
> 
> 	tty[BC]?	serial_line_timer
> 
> where that action could start a process to limit total login time
> allowed for that user on that tty, or something like:
> 
> 	*		check_logger	
> 
> where that action may, say, want to check for logins by
> individuals suspected of doing Bad Things, etc., and set up some type
> of logging mechnism, or something...

Interesting.  Then the command would need the name of the tty by
some other means than writing it as an argument.  Perhaps another
environment variable TTY should be set to the name of the
getty device name when each command is run.

So, with the extensions suggested above, we would have the following
list of environment variables:

	USER=user_name_string
	PATH=system_default_path
	TTY=name_of_the_getty_device

When I considered using the environment to pass information to
the commands run by tty_relatives() I realized that the list of
environment variables would probably change, and I don't like
the idea of changing the argument list for tty_relatives every
time we do that.  So, instead, let's pass a null-terminated list
of environment variables to tty_relatives() like this:

	/* util.h? */
	struct env_list {
		char *env_name;
		char *env_value;
	}
	void tty_relatives(char *filepath, char *ttyname,
	 	struct env_list *);
	
	
	/* in login */
	
	struct env_list cmd_env[4];
	
	cmd_env[0].env_name = "USER";
	cmd_env[0].env_value = pwd->pw_name;
	
	cmd_env[1].env_name = "TTY";
	cmd_env[1].env_value = ttyn;
	
	cmd_env[2].env_name = "PATH";
	cmd_env[2].env_value = _PATH_DEFPATH;
	
	cmd_env[3].env_name = NULL;
	
	tty_relatives(_PATH_TTY_LOGIN, ttyn, env_list);