> > > I'd really rather have it all in one file. See below.
> > 
> > Agreed. One file would be better.
> 
> Please, please, let's keep this to objective arguments.
> Nobody is served by "I like this way better, period."
> WHY is it better?  What is easier or harder either way?

One file would make administration easier (because the login and
logout actions would be in the same place, and because there'd be one
less new file to learn and manage), at the expense of parsing
one extra field in the file (i.e. looking for one more area of
whitespace, snagging the text right before it, and comparing).

I'd call that "better."  8-)


> > > % 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.
> > 
> > Also agreed.
> 
> This lets you have one record apply to many tty lines.
> Is this something people actually want to do or just a
> "creaping feature?"

I think it would be useful in real-world situations.

For instance, as I said: you might want to start a "login timer" on
all modem line logins, and if you've got a rack of modems, it makes
life easier.

On the other hand, that functionality can be implemented without
'glob-like' behaviour, so it may well make sense to implement it
without globs, and see if anybody actually needs it.


> > > % 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.
> > 
> > Necessary, actually, plus the script should be called with a parameter
> > to tell you if you are logging in or out, so that in theory you could
> > have one program do the whole thing.
> 
> You have complete control over the arguments passed to the command.
> With the two file approach you can do this:
> 
> 	# tty_login
> 	console		/etc/console_frob login
> 
> 	# tty_logoug
> 	console		/etc/console_frob logout
> 
> If we used the "one file" approach with an "action" field, this
> could be done as follows:
> 
> 	# ttyactions
> 	console		login	/etc/console_frob login
> 	console		logoug	/etc/console_frob logout
> 
> Or, as Ty suggested, we could allow globbing of the action
> field too and supply $ACTION in the environment.

I think that providing ACTION is better, again from an
ease-of-maintenance standpoint.

which is easiter to maintain:

# tty_login
console		/etc/console_frob login

# tty_logout
console		/etc/console_frob loout

or:

# tty_login
console		/etc/console_frob ${ACTION}

# tty_logout
console		/etc/console_frob ${ACTION}

b
Even in the two file case, that'd be easier for some people, since the
files can be more easily diff'd...


If there was action 'glob' support,  you'd _NEED_ ACTION, but since it
allows lines to be more easily compared (and costs almost nothing in
terms of implementation, if you're using a single 'action' file) it
could make life better.


> I'm not convinced that globbing of either tty names or actions
> actually makes life significantly easeier for anybody, and it
> means doing one (or even two) regcomp();regexec();regrfree()
> calls for each line of the tty_login:tty_logout:ttyactions
> file (which ever of those we use).

I disagree, for a couple of reasons:

	(1) a simpler, non-regexp, globbing mechanism could be used.
	    Certainly, regexps wouldn't be needed for the action
	    field, and indeed, the only 'special' entry might be "*"
	    (which could easily be checked for in any case, to
	    support action wildcarding even if nothing else is
	    wildcarded).

	(2) (either if (1) or regexps) you could check entries for
	    special characters before applying the 'special' match
	    function, and don't appy the special match function
	    if there aren't any regexp/glob characters.


> We do not provide globbing in /etc/ttys so why should we do
> it in the file(s) that specify tty login/logout actions?

As I said above, it's not obvious that we should.  It'd be a nice
feature, but it _is_ expensive, and so perhaps should not be
implemented at first.

It seems to me that this could be easily implemented in such a way
that would allow globbing, or regexp matching, or whatever, to be
easily done later, e.g. by using two (static) functions perhaps
called:
	int match_tty(char *tty, char *file_entry_tty);
	int match_action(char *action, char *file_entry_action);
to do the checks...

I could imagine an implementation which did (modulo KNF 8-):

int
match_tty(char *tty, char *file_entry_tty)
{

	return (strcmp(tty, file_entry_tty) == 0);
}

int
match_action(char *action, char *file_entry_action)
{

	return ((strcmp(action, file_entry_action) == 0) ||
	    (strcmp(action, "*") == 0));
}

and which would easily allow more elaborate comparisons in the future,
without modification to the main body of the ttyaction() (yes, i like
that name 8-) code.



That having been said, my personal opinion on the best proposal so far
for the 'initial, extensible implementation' would use a single file
with entries like:

ttyB0	login	shell_command ${USER} ${ACTION} ${TTY}
ttyB0	logout	shell_command ${USER} ${ACTION} ${TTY}
ttyB1	*	shell_command ${USER} ${ACTION} ${TTY}

etc., and I think I like Ty's names for the function and file.

While i'd like to see 'glob' support for both ttys and actions, I
don't think that _I_ would actually ever use it...  8-)


cgd