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

[Nat!]

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! <nat@mulle-kybernetik.com> 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 +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
> discussion.