From: Bennett E. Todd (bet@cyclone.sbi.com)
Date: 05/14/92


From: bet@cyclone.sbi.com (Bennett E. Todd)
Subject: Re: .login/.profile/.cshrc problems
Date: 14 May 1992 21:19:31 GMT

In article <1992May12.161253.28532@daimi.aau.dk> poe@daimi.aau.dk (Peter Orbaek) writes:
>homer@elec.uq.oz.au (Homer Wong) writes:
>
>>I have tcsh 6.xx installed properly, but for some reason it isn't executing
>>.login or .cshrc (I even tried .profile but no luck) on login. I think
>>I had it executing at one stage, but I installed the shadow password system
>>and now it doesn't. :-(
>
>>The home dir is getting set properly - when the user logs in, they are sitting
>>in their proper home dir, with a '> ' prompt, but that's it.
>
>It's probably not the passwd or shadow files that are the problem.
>
>Regarding the .login file there might be two reasons: Either your tcsh is
>configured for another name, or the login program isn't exec'ing it with a
>'-' prepended to the name (such as -tcsh). Try to make a small program that
>exec's the tcsh with a prepended '-'.

Are you using the /bin/login executable from the mcc-interim 0.95c+ package?

I've seen the same symptoms caused by a different problem. I brought up
rc(1), and, while I could log in with rc as my shell, and end up in the
right directory, it wouldn't read .rcrc. Bash worked fine, reading .profile.

I checked, and the /bin/login binary was messing up the environment. If you
made a login whose shell was printenv, you could see that there was trash
with the high-order bit set in the environment, and important variables like
HOME weren't being set. When I took the login sources from tsx-11, and
recompiled them, the resulting binary worked fine.

Actually, this behavior is within the bounds of Posix 1003.1 Strictly
Conforming, though it doesn't conform to the stricter Posix FIPS (these
claims I take from the book _The_POSIX.1_Standard:_A_Programmer's_Guide_,
by Fred Zlotnick [Benjamin/Cummings Publishing Co., 1991, ISBN
0-8053-9605-5]).

One fix would be to hack every shell you port to Linux the same way Bash is
hacked, so it sets LOGNAME and HOME using getlogin() and getpwuid().
Alternatively, you could write a wrapper program. Set your shell to this
program. Have it figure out LOGNAME and HOME, then exec your shell of
choice.

As a stopgap, if you don't want to build any more binaries, it also works to
have bash as your login shell, and have a .profile that execs your other
shell with the ``-l'' option to make it act like a login shell.

-Bennett (curmudgeon)
bet@sbi.com
"Intel: putting the 'backward' in 'backward compatible'..."