>Well, from bash(1):
>
>| When bash is invoked as an interactive login shell, or as a
>| non-interactive shell with the --login option, it first reads and
>| executes commands from the file /etc/profile, if that file exists.
>| After reading that file, it looks for ~/.bash_profile, ~/.bash_login,
>| and ~/.profile, in that order, and reads and executes commands from
>| the first one that exists and is readable.
>[...]
>| When an interactive shell that is not a login shell is started, bash
>| reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if
>| these files exist.
>
>This of course suggests to put aliases into ~/.bashrc. (or
>/etc/bash.bashrc) But I don't think that helps much. There may be
>millions of people out there, that have put their aliases into
>/etc/profile or wherever, and we have to take care of them too.
But what this says is what Philip experiences is impossible! Without
some major contortions, shell scripts don't run as either login or
interactive shells, so .bash_profile should not run and Philip's
rm -i alias should not affect any shell script or make file.
Also, it takes further contortions (an unusual Bash option setting) to
get a non-interactive shell to use an alias even if you set that alias
explicitly in the script. The designers _really_ didn't want aliases
to affect anything but manual typing.
My own experiments with Bash confirm all this.
So this makes me still curious as to what problem Philip solves by
coding /bin/rm instead of rm. Could there be a different "rm" in his
path that does a "rm -i" thing? Maybe an 'rm' that is sensitive to
the name with which it was invoked?
Since most scripts/make files respect the user's PATH (I know because,
remember, I have a system with no /bin/rm, so when one occasionally
uses "/bin/rm" I notice it), there can't be a whole lot of reliance
out there on them not using rm. But rather than approach the question
from a number-of-people-affected point of view, I think it makes more
sense to approach it from a logical correctness point of view.
For those who are interested, here is the complete story on Bash
profiles, which I've had to look up many times:
- .profile is the login profile. It's supposed to run when you first
start a work session, in the old model where you go up to a terminal,
log in, work for a while, and log out. This is where you put stuff
to tell you if you have mail, give you the joke of the day, etc.
- /etc/profile is the system-wide version of that. It might type out system
maintenance news.
- .bash_profile is the Bash-specific version. Other shells use .profile,
so if you had stuff that works only in Bash, you'd use bash_profile.
- .bashrc is the interactive profile. This is where you put
settings that affect your interactive experience. aliases for
easy typing, terminal colors, history settings, environment
variables for personal preferences, etc.
An example of an interactive shell that is not a login shell is where
you open up a new xterm on your desktop.
- I recall something like .bash_env that is for every shell. But I
can't find it now. In any case, it was never widely used because
shell programs expect a particular standard environment.
A login shell is one invoked with an arg0 that starts with "-" or with
a --login option. An interactive shell is one with a terminal for
Standard Input, that wasn't given a shell script as an argument or a
shell command with a -c option. (Note that a make file rule uses -c).
Remote shells throw a wrench into the works. A traditional Rsh shell
has a socket, not a terminal, as Standard Input, but it really is
interactive; there's a terminal feeding the socket. So Bash has a
special case hack wherein if Standard Input is a socket (and, I think
some other things are true), it assumes you're using Rsh and calls the
shell interactive. This, in turn breaks non-interactive programs that
feed Bash via socket, such as 'scp', so people have to be careful with
their .bashrc. (I myself patch the special case out of Bash and use
Ssh instead of Rsh; it's a lot cleaner. Ssh uses a pseudo-terminal,
so it doesn't need the special case).
--
Bryan Henderson Phone 408-621-2000
San Jose, California
