Re: why ~/.bashrc in ssh or scp??

[Stephane Chazelas]

On Tue, Jan 18, 2005 at 11:02:07AM -0500, Chet Ramey wrote:
> > With csh .cshrc is read by login shells.
> 
> And you can make bash do the same, by sourcing it from .bash_profile.
> 
> > In bash, you need something like:
> 
> You don't, really, but you're welcome to put that in there.

Yes. My question was rather "for what reason did Brian chose to
have the login interactive shells not to source ~/.bashrc?". I
agree it's a choice and it is the one that was made, and that it
is possible to work around it, my question was just "why?".

I found this article by Brian Fox:

http://groups-beta.google.com/group/gnu.bash.bug/msg/770626a4391eea1e
[...]
    ~/.bash_profile is sourced for each login shell. ~/.bashrc is sourced
    for each interactive shell. If you wish to have the same commands
    executed for both login and interactive startups, then explicitly
    "source ~/.bashrc" in your ~/.bash_profile. This allows you to *not*
    have the same commadn executed for both login and interactive startups.
[...]

That makes things a lot clearer to me.

For me, and I'd bet for many people not using bash, ~/.profile
is not a shell customization file, it's a session configuration
file, it defines the environment (environ[], tty settings...)
for every process including the login shell and other shell
processes launched later on during that login session. So in
~/.profile I would put persistent settings accross forks and
execs that make sense all the way through the session and in
~/.shellrc, I would put customizations for the current shell.

For him, if I understand correctly, ~/.profile is just the login
shell customization file the same way as ~/.bashrc is the
customization file for the other shells. The fact that the
settings defined in ~/.profile in the login shell have an impact
on the other shells is not taken into account. So for instance,
for him, PATH should be defined (if needed) both in ~/.profile
and also in ~/.bashrc.

Well, that's a point of view, maybe neither better nor worse
than other's.

Now that most user environments are graphical, it makes thing
quite different from the time when a login session was happening
wholy in a single terminal. Now (except on some operating
systems that still try to launch a shell that reads the
.profile), the user's session configuration are read from a file
(possibly .xsession or .gnomerc or .dtprofile) that is not a
shell startup file any more. So, for a user, setting up an
environment involves more than editing shell startup files and
depends on the operating system and on the desktop environment
chosen. And, as no login shells are started anymore, bash and
other shells don't differ that much. However, the user would
define its environment variables in a ~/.xsession or
~/.dtprofile (so that every command not launched by a shell
would have access to them), and again, in that context also,
having rshd source ~/.bashrc doesn't make any more sense.

What would make sense is a:

~/.profile:
  PATH=$PATH${PATH:+:}$HOME/bin export PATH
  [ "$TERM" = putty ] && stty erase '^H'

~/.gnomerc:
  [ -f ~/.profile ] && [ -r ~/.profile ] && . ~/.profile

~/.shellrc:
  alias ls='ls --color=tty'
  shopt -s failglob
  set -u

~/.rshrc:
  [ -f ~/.profile ] && [ -r ~/.profile ] && . ~/.profile
  # rsh specific settings
  

With a login shell running ~/.profile and every interactive
shell running ~/.shellrc and when I want to do a rsh and have my
session settings applied: rsh host '. ~/.rshrc; cmd'.

This way for every X or not session (gnome, telnet, rlogin,
console), ~/.profile is read; the ~/.shellrc is run by every
interactive shell, the ~/.rshrc is run only when I want without
disrupting applications that rely on a normal behavior of rsh.

If I want to do the same with bash, it's a bit more convoluted:

~/.profile:
  PATH=$PATH${PATH:+:}$HOME/bin export PATH
  [ "$TERM" = putty ] && stty erase '^H'

~/.bash_profile:
  [ -f ~/.profile ] && [ -r ~/.profile ] && . ~/.profile
  case $- in
    *i*)
      [ -f /etc/bash.bashrc ] &&
        [ -r /etc/bash.bashrc ] &&
        . /etc/bash.bashrc
      [ -f ~/.bashrc ] &&
        [ -r ~/.bashrc ] &&
        . ~/.bashrc;;
  esac

~/.gnomerc:
  [ -f ~/.profile ] && [ -r ~/.profile ] && . ~/.profile

~/.bashrc:
  if [ -z "${BASH_EXECUTION_STRING+set}" ]; then
    alias ls='ls -F --color=tty'
    shopt -s failglob
    set -u
  fi

~/.rshrc:
  [ -f ~/.profile ] && [ -r ~/.profile ] && . ~/.profile
  # rsh specific settings



BTW, is there a detailed Changelog somewhere for bash versions
prior to 1.11 or any way to get the source of those old
versions? I can see that the rsh /feature/ may have been
introduced in 1.05 but that's just a guess from a usenet post by
Brian Fox in 1990.
(http://groups-beta.google.com/group/gnu.bash.bug/msg/1ad0443df7fa52e1)
(that's just out of curiosity).

-- 
Stéphane