Forcing actions at login
Dik T. Winter
dik at cwi.nl
Thu Jan 24 12:18:37 AEST 1991
In article <1991Jan23.191016.20988 at mp.cs.niu.edu> rickert at mp.cs.niu.edu (Neil Rickert) writes:
> Whether all this is really worth the trouble is quite questionable.
>
Depends. When you need it for accounting the trouble is worthwile. For all
other situations you should not force users to go through some predefined
actions. I have seen many solutions, one of them provided a system wide
profile that asked for terminal type. That is gross, unless it is possible
to overrule it. Consider a section of my 500+ lines profile (where TERM
has just been read, or has been gotten through the network):
if grep "$TERM" $HOME/lib/termcap >/dev/null 2>&1
then
TERMCAP=$HOME/lib/termcap
fi
if test -f $HOME/lib/terminfo/*/$TERM
then
TERMINFO=$HOME/lib/terminfo
fi
export TERMCAP TERMINFO
eval `tset - -Q -s`
Yes, I like my own personalized terminal descriptions, but sometimes I want
the standard ones, but that depends on the way I got onto the machine (telnet,
direct, rlogin etc.).
Also, on some machines I have access to, /etc/profile is executed twice when I
login. Once when my login shell is started (/bin/sh on those machines). The
shell soon executes the command 'exec -myshell' which starts my own shell.
This one dutifully reexecutes /etc/profile. So I get twice /etc/motd while
zero times is enough in my opinion.
Further, why does /etc/profile check for mail in SysV UNIX? I read my mail
on one machine only, but the mailbox is NFS mounted on all machines. I do
not want to see that message any time I login to some random machine.
Luckily our system administrator could be convinced to do it conditional on
.hushlogin (it did not need much convincing).
Summary: you should only force something on the user if it is related to
accounting; nothing else. You should never force a particular PATH; you
may give him some functions/aliases that can make life simple. But he
should be able to redefine/undefine them.
--
dik t. winter, cwi, amsterdam, nederland
dik at cwi.nl
More information about the Comp.unix.admin
mailing list