"Jeremy C. Reed" <reed@reedmedia.net> writes:

>- and root's actual login scripts, i.e., /root/.login, /root/.profile.
>  but usually these scripts are only read and used by the appropriate
>  shell (for example, csh is not going to use .profile and ksh is not
>  going to use .login). I could see a problem if these scripts were
>  changed or read and used (sourced) instead of executing other
>  incompatible scripts.

there's no problem having a _statically linked_ tcsh in /bin for
root, however, if you just make a symlink to /usr/pkg/bin/tcsh or
put the dynamically linked binary in /bin, you will run into problems
if somehow /usr/lib gets inaccessible or the libraries in question get
corrupted or sth.  Of course, you then could still reboot into single-
user because it asks for which shell to use and defaults to /bin/sh
but you could not fix things then when the system goes belly-up in
multiuser (however, you could enable the "toor" account and put
/bin/{sh,ksh,csh} there and use it in case of emergency of course.)
Not so long ago, someone also mentioned the use of "su -m", where
it'll substitute the user but keeps your current user's environment,
working directory and login shell, which might be preferrable to any
messing with root's login shell.

mkb