Bash sources /etc/bashrc

[reckbo]

Issue description

Why is bash built with

NIX_CFLAGS_COMPILE = ''
-DSYS_BASHRC="/etc/bashrc"
...

by default? The reason I ask is that 1) it reduces purity, and 2) I have nix installed in a cluster environment with no root access, and their /etc/bashrc pollutes my environment -- for example it sets LD_LIBRARY_PATH, which in turn breaks packages such as sed and coreutils (see
errors below).

Reproducible Steps

# below will source '/etc/bashrc' by default
bash
nix-shell

Workarounds are:

bash --norc
nix-shell --run 'bash --norc'

Errors caused by invasive /etc/bashrc

bash: shopt: progcomp: invalid shell option name
sed: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by sed)
bash: sed: command not found
bash: uname: No such file or directory
bash: grep: No such file or directory
bash: sed: No such file or directory
bash: sed: No such file or directory
bash: sed: No such file or directory
bash: sed: No such file or directory
bash: complete: No such file or directory
bash: perl: No such file or directory
bash: uname: No such file or directory
bash: rm: command not found
/data/pnl/soft/nix/store/mjdmg9yslbc5r9176vkpv0vd6k94y7vx-coreutils-8.25/bin/coreutils: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by /data/pnl/soft/nix/store/mjdmg9yslbc5r9176vkpv0vd6k94y7vx-coreutils-8.25/bin/coreutils)
/data/pnl/soft/nix/store/mjdmg9yslbc5r9176vkpv0vd6k94y7vx-coreutils-8.25/bin/coreutils: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /data/pnl/soft/nix/store/mjdmg9yslbc5r9176vkpv0vd6k94y7vx-coreutils-8.25/bin/coreutils)

[deepfire]

@FRidh -- what feedback is needed?

[deepfire]

Related:
-- NixOS/nix#976
-- NixOS/nix#903

[edolstra]

IIRC, this is to ensure that the environment is properly initialised in all cases on NixOS (including e.g. when logging in via ssh host <command>). It might not be necessary (anymore), but this would have to be checked carefully to prevent introducing any regressions.

[mmahut]

Are there any updates to this issue, please?

[stale]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.

[buffet]

To add to this: When launching bash from inside nix develop, I get bash: shopt: progcomp: invalid shell option name, and a lot of stuff breaks (e.g. all readline related functionality).

[samueldr]

Nixpkgs software still follows their system-wide configuration semantics.

Using Nixpkgs' bash outside of NixOS leads to unexpected side-effect, but those side-effects are not exclusive to bash. Singling-out bash here seems like it would cause more issue than it may solve.

nix-shell is not intended to be an isolation layer from the system.

I believe this issue can be closed under this understanding.

Usage of bash in tooling is not affected by this, the rc files being read only in interactive scenarios.

The issues this may cause should be handled where it happens.

---

If this is wrong, feel free to comment and detail why this should be re-opened. (Or re-open yourselves with explanation if you have the ability to do so.)

[buffet]

The issues this may cause should be handled where it happens.

@samueldr Should I open an issue for NixOS' /etc/bashrc then, or are you saying "this is bash's issue"?

[samueldr]

@buffet: yes, an issue dedicated to this problem, with the details about how you have determined this is caused by the /etc/bashrc being read.

It sounds like there is a problem indeed with what you were observing, but the solution is unlikely to be "prevent bash from reading /etc/bashrc" outright, but more likely related to its less-than-hermetic invocation elsewhere.

It could also be some other more nuanced issue with your system configuration, so precise steps in reproduction would be really helpful.

(Do ping me, and cross-reference this issue.)

[buffet]

Time to figure out what I was doing 1.5 years ago...