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!
