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

[Nat!]

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!