bash --rcfile does not behave as documented

here are two "upstream" bugs (debian is upstream, right?)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516152
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343673

note: those two bugs are duplicates of each other, but i was not able to find out how to mark bugs as duplicate in the debian bug tracker.

Yes, I confirmed it. Ubuntu 10.04 bash. when execute "/bin/bash --rcfile someexistedrcfile", it still read and execute /etc/bash.bashrc and will not read ~./bashrc

Merged the two Debian bugs for you.

Debian bug #516152 is from 2009, and #343673 from 2006 ... none of them are fixed, so I don't think they care.

This is not an irrelevant package we are talking about, its a flaw in invocation of something critical like bash. Is there any chance this could be patched ASAP in Ubuntu and then the patch submitted to Debian afterwards?

Also, this is not only a bug in documentation as #516152 and #343673 suggests: with current behaviour, it's impossible to "disable" the execution of /etc/bash.bashrc and still give the user a choice of executing a personal rcfile.

Samples:

$ cat /etc/bash.bashrc
echo etcbashrc
$ cat ~/customrc
echo customrc
$ cat ~/.bashrc
echo bashrc
$ bash
etcbashrc
bashrc
$ bash --rcfile ~/customrc
etcbashrc
customrc
$ bash --norc --rcfile ~/customrc
$

This patch fixes the behaviour of --rcfile. It was also reported in both Debian and upstream. But since Ubuntu is usually much more responsive, the fix could be patched in Ubuntu until either Debian or GNU merges.

Also, to speed things up, everyone interested could voice their opinion in GNU's bug report at https://savannah.gnu.org/support/index.php?107950 , there's a VOTE section that maybe would help getting attention to this issue

The attachment "Do not execute /etc/bash.bashrc if --rcfile is set" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[TL;DR: Bash developer Chet Ramey claimed in 2015 that this is a documentation bug. Then, in 2016, a documentation patch has been proposed to (and possibly accepted by?) Debian.]

On 16 Sep 2016, Chet Ramey released version 4.4 of bash. This inspired me to check and see if this long standing issue has been fixed. Here is what I learned.

Debian bug # 343673 from 2005.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343673

Debian bug # 516152 from 2009.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516152

GNU Savannah bug #107950 from 2012.
https://savannah.gnu.org/support/index.php?107950

In 2015, Chet Ramey commented on the above Savannah bug report:

"Debian made that documentation error. If you compile with -DSYS_BASHRC, it's always executed, as is ~/.bashrc (or the file specified with --rcfile)"

In other words, Ramey claims this is a documentation bug. I do not know if -DSYS_BASHRC has only the one above effect, or if it also has other effects as well.

In 2016, Tom Levy posted the following comment on Debian bug #516152 (see above link).

"Convincing Chet that the behaviour in Debian's documentation is preferable
to the current behaviour seems hard considering his 3-year response time. I propose changing the documentation."

Levy also included a patch to Debian's bash man page. The patch is here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?att=3;bug=516152;filename=man-bashrc.diff.patch;msg=27

I am not an expert on the Debian development process, so I am unable to determine if the patch has been accepted by Debian.

The patch does not appear to have been applied to the following file, but this might not be the correct place to look for the patch. (Again, I am not a Debian expert.)

http://sources.debian.net/src/bash/4.4-1/doc/bash.1/

What is the status of this? There is a further discussion from Chet here:

https://<email address hidden>/msg20804.html

Why does Debian enable -DSYS_BASHRC? This question does not seem to be answered anywhere.

Is there a workaround? Can someone release an alternate version of bash for Ubuntu without -DSYS_BASHRC?

> Why does Debian enable -DSYS_BASHRC? This question does not seem to be answered anywhere.

It does make sense for Debian (and Ubuntu) to enable SYS_BASHRC by default, as a system-wide /etc/bash.bashrc is a useful (and needed) configuration tool for sysadmins. It's standard behavior for many packages to read system-wide config file(s) from /etc and then merge user settings from ~/.* or ~/.config, so I don't think this is the issue.

> Is there a workaround? Can someone release an alternate version of bash for Ubuntu without -DSYS_BASHRC?

There's no need for an alternate release: if you have enough privileges to install system-wide software with apt, it means you're the admin who can also edit /etc/bash.bashrc to be a blank file to effectively disable it.

If you're not the admin but want a custom bash for your user, you can compile bash yourself (without -DSYS_BASHRC or patched with a correct --rcfile behavior) and install it at ~/.local/bin.

So admins can easily modify/disable /etc/bash.bashrc, and non-admins are not supposed to be able to bypass it anyway, at least for login shells.

----

I believe the issue is not -DSYS_BASHRC being enabled by default, but rather `--rcfile` not behaving as it should, and documentation that mismatches current behavior.

My use case: I want to be able to spawn a clean shell with a customized development environment (python) from a Makefile (i.e. `make shell` runs `bash --init-file .init_file.bash` which does not inherit cruft from the environment (such as activated conda environments, PATHs etc.)

```
shell:
    bash --init-file .init_file.bash
```

This worked fine until I started trying to use this on Debian-based systems with -DSYS_BASHRC where, sometimes, admins activate a conda environment for all users by default.

So, no admin access in the typical case. Now a user can do this by running `bash --norc` then manually sourcing `.init_file.bash` from that shell.

How do I achieve this effect from my Makefile? This is what I would have expected `bash --norc --init-file .init_file.bash` but that is not what bash does. I tend to agree that ignoring `--rcfile` flag behaviour with `--norc` is the error... but it looks like that is not going to change.

So what do I do? That non-admins are "not supposed to be able to bypass it" seems moot, since they can with `--norc`. Am I missing something?

Merging with LP: #1097467, as documentation fixes are happening there to reflect long-standing upstream desired behavior.