Ubuntu
bash package

bash does not fulfill --rcfile option properly

Bug #1097467 reported by Hugo Heden
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
bash (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

I am starting a bash shell using

$ bash --noprofile --rcfile my-custom-bash-rc-file

Due to the --rcflag, the newly started bash should *not* execute commands from /etc/bash.bashrc. That is at least how I interpret `man bash`:

      --rcfile file
              Execute commands from file instead of the system wide initialization file /etc/bash.bashrc and the standard personal initial‐
              ization file ~/.bashrc if the shell is interactive (see INVOCATION below).

However, it seems that the commands in /etc/bash.bashrc are in fact executed.

To see/reproduce/diagnose this, on Ubuntu I believe one can just invoke bash like this (as the regular user):

$ touch testrc
$ env -i bash --noprofile --rcfile testrc

The expected result would be that nothing special is printed on the terminal. However, there is an error message, which is printed from /etc/bash.bashrc. The "env -i" causes $HOME to not be set in the invoked shell, which in turn triggers the error. The error message is:

> To run a command as administrator (user "root"), use "sudo <command>".
> See "man sudo_root" for details.

Another way to see this -- without the "env -i" -- is to add a command to /etc/bash.bashrc, such as

echo HELLO THERE

To trigger the bug(?), one can then just do

$ touch testrc
$ bash --noprofile --rcfile testrc

The expected result would be that nothing special is shown in the terminal. However, it turns out that the string

HELLO THERE

is printed.

See original description
Revision history for this message
Hugo Heden (hugoheden) wrote :

$ lsb_release --all
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.10
Release: 12.10
Codename: quantal

$ bash --version
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Dave Jones (waveform)
summary: - bash does not fulfill --bashrc option properly
+ bash does not fulfill --rcfile option properly
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in bash (Ubuntu):
status: New → Confirmed
Revision history for this message
Dave Jones (waveform) wrote :

This has apparently been an issue for some considerable time. I've just now run into it while delving into a failure in pexpect's test-suite (during work on LP: #1987420), which apparently assumes that using --rcfile will suppress both the user *and* the system's bashrc (as the man-page documents).

However, I'm not entirely convinced this is a bug in bash, so much as its man-page. Reading the original code (shell.c in bash) its intent is fairly clear: execute the system-wide bashrc in all interactive shells, but permit the user's bashrc to be overridden by --rcfile.

It's worth noting that the original (upstream, not Debian) man-page makes no mention of the system-wide bashrc because it's an option that's not activated by default. The Debian packaging enables the system-wide bashrc (SYS_BASHRC in d/p/deb-bash-config.diff) and then patches the man-page to mention it (d/p/man-bashrc.diff). In other words, I suspect this is a documentation bug rather than a behavioural bug (i.e. the man-page is wrong, not the behaviour).

Revision history for this message
Dave Jones (waveform) wrote :

Hmm, on the other hand --norc does indeed suppress both user and system-wide bashrc files. So, the man-page is correct in that instance, and apparently the intent of bash is to allow the system-wide bashrc file to be suppressed in certain circumstances. Which sways me back toward the notion that the bug is in bash's --rcfile behaviour ...

Revision history for this message
Dave Jones (waveform) wrote (last edit ):

I'm unsure what the "correct" solution is here; could be that bash's behaviour is wrong, or it could be that the documentation is wrong. Rather than decide, I'm taking the cowards way out and attaching patches for both solutions, leaving it to the maintainer to decide which is appropriate :)

Revision history for this message
Dave Jones (waveform) wrote :
Revision history for this message
Dave Jones (waveform) wrote :
tags: added: rls-kk-incoming
Revision history for this message
Julian Andres Klode (juliank) wrote :

This discussion needs to be taken upstream, it's not our place to decide what is right.

tags: removed: rls-kk-incoming
Nick Rosbrook (enr0n)
Changed in bash (Ubuntu):
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.