Use of --rcfile does not preclude read of /etc/bash.bashrc
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib
-Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/build/bash-IrsGKQ/bash-4.4=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall -no-pie
-Wno-parentheses -Wno-format-security
uname output: Linux terodde 4.13.0-21-generic #24-Ubuntu SMP Mon Dec 18
17:29:16 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.4
Patch Level: 12
Release Status: release
Description:
The documentation states, that /etc/bash.bashrc should not be read
(rightfully so IMO) with
--rcfile.
--rcfile file
Execute commands from file instead of the system wide
initialization file /etc/bash.bashrc and the
standard personal initialization file ~/.bashrc if the
shell is interactive (see INVOCATION below).
Yet it does and it pollutes my values.
Repeat-By:
nat@terodde:/tmp$ echo 'echo $PS1' > x.sh
nat@terodde:/tmp$ echo 'exit' >> x.sh
nat@terodde:/tmp$ PS1='>>>' strace -o trace bash --noprofile
--rcfile x.sh
${debian_chroot:+($debian_chroot)}\u@\h:\w\$
nat@terodde:/tmp$ grep bashrc trace
openat(AT_FDCWD, "/etc/bash.bashrc", O_RDONLY) = 3
read(3, "# System-wide .bashrc file for i"..., 2188) = 2188
Ciao
Nat!
Re: Use of --rcfile does not preclude read of /etc/bash.bashrc
I tried to come up with a workaround, but I couldn't find any.
Basically what I do:
env -i bash --norc --noprofile
This gives me an interactive shell, with a very clean environment (even
no PATH), that does not contain system specify "surprises".
This works.
But what I really want is to set up a custom environment before going
interactive.
env -i bash --norc --noprofile --rcfile custom.sh
This doesn't work, because --norc (IMO) incorrectly preempts the
--rcfile use, where's the point ?
The command
env -i bash --noprofile --rcfile x.sh
does work to my satisfactions on systems, that do not enable SYS_BASHRC
(OS X).
So if --rcfile was a feature earlier than SYS_BASHRC (2.05), it's a bona
fide regression.
Ciao
Nat!
On 03.01.2018 02:39, Eduardo Bustamante wrote:
On Tue, Jan 2, 2018 at 3:05 PM, Nat! wrote:
[...]
Description:
The documentation states, that /etc/bash.bashrc should not be read
(rightfully so IMO) with
--rcfile.
FWIW, there are two things going on here:
(1) /etc/bash.bashrc is actually disabled by default in the upstream
bash source code distribution and it's not documented:
$ grep SYS_BASHRC config-top.h
/* #define SYS_BASHRC "/etc/bash.bashrc" */
(2) The behavior you observe (SYS_BASHRC and bashrc_file both being
sourced) has been in place for a few years now (since bash 2.05 at
least), so I don't think it's a good idea to change this now in
upstream code, given that it'll potentially affect users that rely on
this to behave in a certain way for distros that enable SYS_BASHRC.
$ git blame shell.c | sed -n '1187,1198p'
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 + 1187) /* bash */
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 + 1188) if
(act_like_sh == 0 && no_rc == 0)
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 + 1189) {
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 + 1190) #ifdef SYS_BASHRC
b72432fdc (Jari Aalto 1999-02-19 17:11:39 + 1191) # if defined (__OPENNT)
b72432fdc (Jari Aalto 1999-02-19 17:11:39 + 1192)
maybe_execute_file (_prefixInstallPath(SYS_BASHRC, NULL, 0), 1);
b72432fdc (Jari Aalto 1999-02-19 17:11:39 + 1193) # else
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 + 1194)
maybe_execute_file (SYS_BASHRC, 1);
bb70624e9 (Jari Aalto 2000-03-17 21:46:59 + 1195) # endif
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 + 1196) #endif
28ef6c316 (Jari Aalto 2001-04-06 19:14:31 + 1197)
maybe_execute_file (bashrc_file, 1);
^726f6388 (Jari Aalto 1996-08-26 18:22:31 + 1198) }
As you can see, the wording that you report is not present in the
upstream distribution, so this is likely a debian patch.
$ PAGER= man doc/bash.1 | grep -e '^[[:space:]]*--rcfile file' -A3
--rcfile file
Execute commands from file instead of the standard
personal initialization file ~/.bashrc if the shell is interac‐
tive (see INVOCATION below).
IMO, the right thing to do here would be to ask the Debian package
maintainer to correct the wording to indicate that both
/etc/bash.bashrc AND the file provided by --bashrc are executed.
Important to note here also that SYS_BASHRC is a mechanism exposed for
sysadmins who want to ensure that a certain configuration is applied
system-wide, regardless of what the users of the system desire. If
it's a system you control, you can always re-compile bash or remove
the file.
See: https://lists.gnu.org/archive/html/bug-bash/2009-05/msg00035.html
and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516152 for prior
discussion.
Re: Use of --rcfile does not preclude read of /etc/bash.bashrc
Chet Ramey schrieb:
On 1/6/18 8:14 AM, Nat! wrote:
It's not incorrect; --norc is intended to suppress execution of the
interactive shell startup files, even if you specify another file to not
execute.
Without any warning ? The man of the --norc option specifies exactly
which files it is not reading. It's clearly not saying anything about
ignoring the user specified --init-file.
You have to infer this indirectly, thinking how bash probably does it:
```
init_file=${init_file:-~/.bashrc}
if [ -z ${norc} ]
. ${SYS_BASHRC}
. ${init_file}
fi
```
when it could (and should IMO) do
```
if [ -z ${norc} ]
. ${SYS_BASHRC}
. ${init_file:-~/.bashrc}
else
if [ ! -z ${init_file} ]
then
. ${init_file}
fi
fi
```
You could use $ENV, but that's only effective for shells started in
Posix mode.
The command
env -i bash --noprofile --rcfile x.sh
does work to my satisfactions on systems, that do not enable SYS_BASHRC (OS
X).
So if --rcfile was a feature earlier than SYS_BASHRC (2.05), it's a bona
fide regression.
It's not a regression.
As I understand it, w/o SYS_BASHRC the combination of --noprofile
--rcfile suppresses all "code injection" from initfiles into the bash
shell. I would argue that is the intention of someone using --rcfile.
If someone goes to the trouble of typing "bash --rcfile" he surely is
not "logging in" or connecting via "ssh", something that's under the
intent of an administrator. It's a user/developer trying to set up a
custom environment. SYS_BASHRC negates that. So it is a functional
regression from that point on.
The sole intent of SYS_BASHRC was to allow system
administrators who wanted a file sourced before the user's interactive
shell startup file (e.g., to make sure that some environment variables were
set) to specify one. It's not intended to be overridden, and it's executed
under the same circumstances as the user's bashrc file.
I would guess, due to the funky ways the bash sources various differing
files during session login and ssh, the main reason for SYS_BASHRC was
to have a single point of modification for people logging into the system.
Or were admins really worried about people using --rcfile and missing
out on their valuable environment variables ? And why would that be more
important than the user choice ?
SYS_BASHRC narrows the use of bash from being a viable (interactive)
language interpreter to just being a login shell. Not everyone is an
admin or user, some people are developers too, especially on debian :)
I found a few predecessors to my query, so I am not the only one and it
is clearly negating user intent:
https://savannah.gnu.org/support/?107950
https://lists.gnu.org/archive/html/bug-bash/2009-05/msg00035.html
(SYS_BASHRC was inserted in August, 1995 and made its first public
appearance in bash-2.0. Discussion started a few months prior.)
It would be interesting to read that discussion. Is it archived somewhere ?
Ciao
Nat!
