[MacPorts] #40603: MacPorts bash doesn't work properly as a default shell (should define SH_SOURCE_BASHRC)

[MacPorts]

#40603: MacPorts bash doesn't work properly as a default shell (should define
SH_SOURCE_BASHRC)
----------------------+----------------------
  Reporter:  dlitz@…  |      Owner:  raimue@…
      Type:  defect   |     Status:  assigned
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:  2.2.0
Resolution:           |   Keywords:
      Port:  bash     |
----------------------+----------------------

Comment (by dlitz@…):

 Thanks, but one clarification:

 > The usual workaround for the different startup files for interactive and
 > login shells would be to to source .bashrc from your .bash_profile.

 That's about login vs non-login shells, and SSH_SOURCE_BASHRC doesn't
 change
 that behavior.  This is about running .bashrc from a ''non-interactive''
 shell,
 such as when you try to use `git pull` over SSH from a repository on your
 Mac.

 > The bash upstream maintainer actually advises against it (that's why it
 isn't
 > enabled by default). I am in the process of checking which other
 > distributions enable this as well, but it seems like almost every Linux
 > distribution does it.

 I assume you're referring to this comment by Chet Ramey[1]:

 > Here's the problem:  consider a user who runs a shell that doesn't
 understand
 > $SHLVL in the same way bash does (they do exist).  They ssh to a system
 with
 > bash modified with SSH_SOURCE_BASHRC enabled.  Every time they run,
 > explicitly (unlikely) or via some other agent (more likely), `bash -c
 > command', their .bashrc file, if it exists, will be read, as will the
 system
 > /etc/bashrc if that's been enabled.  This will lead to some really
 obscure
 > bug reports.  It's happened.

 Chet's criticism is valid.  Adding special-case knowledge of SSH into the
 shell
 is a dirty hack, and it would be better if everyone could agree on some
 way of
 allowing the user to set environment variables dynamically prior to
 loading the
 shell (e.g. in a PAM module or something).  However, that has its own
 problems,
 e.g. for "restricted shells".  Right now, it seems that there's no easy,
 clean
 solution and it doesn't seem to be on anybody's agenda to actually solve
 this
 problem any time soon (especially in a cross-platform way).

 Right now, setting environment variables on OSX outside ~/.bashrc is a
 pretty
 big mess[2].  SSH_SOURCE_BASHRC is quite clean, in comparison, and much
 more
 flexible.

 There's a reasonable argument that SSH_SOURCE_BASHRC is the wrong approach
 to
 this problem in general.  However, the fix is something that can only be
 properly solved by the OS vendor.  The issue that Chet points out isn't
 solved
 by having MacPorts bash behave differently from Apple bash: Programs on
 OSX
 need to cope with the behavior of Apple bash anyway.

 So, despite the (valid) criticism of this approach in general, it would
 still
 be better if MacPorts bash behaved the same Apple bash here, regardless of
 what
 other distros do.

 At the moment, using MacPorts bash as my login shell breaks `git pull my-
 mac:~/path/to/repo`.

 [1] http://lists.gnu.org/archive/html/bug-bash/2007-12/msg00028.html
 [2] http://stackoverflow.com/questions/603785/environment-variables-in-
 mac-os-x/4567308#4567308

-- 
Ticket URL: <https://trac.macports.org/ticket/40603#comment:3>
MacPorts <http://www.macports.org/>
Ports system for OS X