[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use of --rcfile does not preclude read of /etc/bash.bashrc

From: Nat!
Subject: Re: Use of --rcfile does not preclude read of /etc/bash.bashrc
Date: Sat, 6 Jan 2018 14:14:00 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

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.



On 03.01.2018 02:39, Eduardo Bustamante wrote:
On Tue, Jan 2, 2018 at 3:05 PM, Nat! <address@hidden> wrote:
     The documentation states, that /etc/bash.bashrc should not be read
(rightfully so IMO) with
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 +0000 1187)       /* bash */
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1188)       if
(act_like_sh == 0 && no_rc == 0)
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1189) {
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1190) #ifdef SYS_BASHRC
b72432fdc (Jari Aalto 1999-02-19 17:11:39 +0000 1191) #  if defined (__OPENNT)
b72432fdc (Jari Aalto 1999-02-19 17:11:39 +0000 1192)
maybe_execute_file (_prefixInstallPath(SYS_BASHRC, NULL, 0), 1);
b72432fdc (Jari Aalto 1999-02-19 17:11:39 +0000 1193) #  else
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1194)
maybe_execute_file (SYS_BASHRC, 1);
bb70624e9 (Jari Aalto 2000-03-17 21:46:59 +0000 1195) #  endif
ccc6cda31 (Jari Aalto 1996-12-23 17:02:34 +0000 1196) #endif
28ef6c316 (Jari Aalto 2001-04-06 19:14:31 +0000 1197)
maybe_execute_file (bashrc_file, 1);
^726f6388 (Jari Aalto 1996-08-26 18:22:31 +0000 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]