On Mon, Jul 04, 2005 at 11:00:57AM +0300, Nadav Har'El wrote: > On Mon, Jul 04, 2005, Yedidyah Bar-David wrote about "Re: users' .bashrc not > getting executed?": > > bashrc isn't sourced on login shells, only on interactive non-login > > shells. I guess root's .profile or .bash_profile sources .bashrc or > > something like that. > > I wonder why this is so. The situation is certainly differrent in Ksh > and in Zsh, where the $ENV or .zshrc is executed on *any* interactive > shell, login shell or not. The traditional division between the "profile" > and "rc" ($ENV in Ksh nomenclature), was that the profile was read only > in one "login shell" that is the parent of all others, and thus should > contain only inheritable settings, especially exported variables and > "umask" settings. The "rc" file would contain things that cannot be inherited > and are specific to interactive shells (on the last point, the behavior > in tcsh is different), such as aliases, functions (which were inheritable > in the original ksh, by the way), and "stty" settings.
But what if ENV isn't set in profile? Nothing gets sourced (in sh-compatibility mode). ash doesn't even have a "compatibility" mode - that's its only behaviour (only /etc/profile ~/.profile and ENV if set). > > So I was suprised to learn today that indeed, bash default behavior > is not to run the .bashrc on an interactive login shell. I find this > extremely strange... By the way, I see now in bash's manual, that if > it is invoked as "sh" (rather than "bash"), it uses the ksh-like ENV > variable and its behavior. I agree it's a bit strange, but it's not a real problem practically. Only causes bugs such as Ira's (if that indeed was the thing). I personally simply have .profile linked to .bashrc and that's it. > > P.S. I'm a very happy user of Zsh. Yes, we know that. You remind us often :-) I admit your pressure was enough that I tried it a few years ago, after using tcsh for many years, for a few months, and then moved to bash. Of course zsh is more powerful, but bash is more standard, so I can rely on it being installed and being the default in almost all new machines I encounter. > It has its share of peculiarities, but > not this one, so you can consider switching :-) Indeed a good enough reason :-) -- Didi ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
