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

not strictly 'need'.  `id -gn ${USER}` could work in place of ${GROUP}.
If it's not too much trouble, it'd be nice...  I dunno how much
trouble it would be.


> Might be nice to have TTY as the login tty's name.

yeah; i pointed out the need for something like this in my reply to
gordon's mail, though I don't care what it's named as long as it's
sane...  8-)


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

again, i'd really like to get rid of the full paths in the tty name
field, and replace them with the names used in /etc/ttys, unless
there's a good reason not to.

as for specifying both login and logout, sounds reasonable to me, and
allowing that to be wildcarded, sounds reasonable to me as long as
there's not too much implementation hair.


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

"i dunno."



cgd