Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!AI.MIT.EDU!tmb
From: tmb@AI.MIT.EDU (Thomas M. Breuel)
Newsgroups: gnu.bash.bug
Subject: Re: bash seems to execute ".profile" when it shouldn't
Message-ID: <8909130140.AA03372@wheat-chex>
Date: 13 Sep 89 01:40:47 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 28


	to quote from my locally hacked version of bash 1.03:
	|   /* This is the only way I know how to find an rsh shell.
	|      If this shell is remote (rsh host command), then make
	|      sure that we run the .login stuff so that the user can
	|      set his/her PATH. */

	 It's a feeture. Honest. Feel free to ifdef it out; I do.

If rsh wanted a login shell, it would invoke the shell with a "-" as 
its first argument. For a variety of reasons, rsh doesn't. If that's
the behavior someone wants for rsh, he should change the behavior
of rsh, not of the shell.

The reason why it's a bad idea to make the shell source the .profile
is that (1) .profile's are written with the assumption that they'll
only get executed on login, so they will often change tty modes 
(which gives error output when done from inside rsh) and ask
for user input (like terminal type); (2) someone may just type "bash"
from another non-bash shell and have his .profile executed
(and what about a bash script that is executed by a non-bash user? What
about "bash file"? What about "bash < file"?)

Now, as far as I'm concerned, it would be OK if bash executed
a ".bash_login" file (I would simply not have one of those). However, 
the semantics of the .profile are determined by the Bourne shell, 
and if bash deviates too far from them, it will be impossible to go 
back and forth between the two.