>> [...allow shell arguments in the password file...]

> Think of the implications this has for chsh and /etc/shells.

Argh.  Yet another problem caused by /etc/shells.

Why are we still using /etc/shells for anything at all?  I've yet to
see a good use for it.  I saw it go in as a "fix" to the "chsh to shell
with colons and newlines" problem.  While it's true it closed that
hole, it also broke the "shell is just another program" paradigm.

Nowadays it seems to get used as "a login with a shell in /etc/shells
is a human with shell access, anything else is a captive account".

This makes mistakes: I (relatively) often have logins on systems where
I can't write /etc/shells, but want to run my shell instead of being
stuck with one of the vendor shells.

It also assumes that all captive accounts are the same.  They're not;
witness /etc/ftpusers, and note that ftpd _still_ checks /etc/shells
(or at least its manpage says it does), despite having its own
mechanism.

What is /etc/shells good for?  Anything?  Or is it just following a
tradition started by someone looking for a quick fix?  Even if it still
has some use, I'd really like to see a way that I, as a sysadmin, can
configure it such that _any_ program is considered a "standard shell".
With /etc/shells as it stands, the only way to do that is something
like "find / -type f -print > /etc/shells", and that (a) will make
getusershell() take _forever_ and (b) needs to be rerun every time
someone compiles a new program.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D