[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: Wed, 10 Jan 2018 00:19:14 +0100
User-agent: Postbox 4.0.8 (Macintosh/20151105)

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

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:

if [ -z ${norc} ]
   . ${SYS_BASHRC}
   . ${init_file}

when it could (and should IMO) do

if [ -z ${norc} ]
   . ${SYS_BASHRC}
   . ${init_file:-~/.bashrc}
   if [ ! -z ${init_file} ]
      . ${init_file}

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

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:


(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 ?


reply via email to

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