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

[Chet Ramey]

On 1/9/18 6:19 PM, Nat! wrote:
> 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.

That's how it's always worked. From the earliest days of the feature -- and
I'm talking even before the 0.98-0.99 days in 1989 -- the --norc option
inhibited sourcing the per-user interactive shell startup file. If the user
wanted to specify a different file, that was the file the shell didn't
source. The --rcfile says which file you want to execute, the --norc option
says you don't want to execute it. This doesn't have anything to do with
SYS_BASHRC.

If you want to talk about improving the documentation, which has said just
about the same thing since 1991 or so, we can do that. Inserting the words
"or the file supplied as an argument to the --rcfile option" would suffice.


> 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
> ```

Yeah, it's literally never done that.

>>> 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.

No. The combination of --noprofile --norc suppresses all such "code injection".

> 
> 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.

Since that's not the point of SYS_BASHRC, this doesn't make much sense.
The personal initialization file, whatever its name, is sourced after
SYS_BASHRC, so there's nothing preventing a developer from setting up a
custom environment and overriding everything he doesn't like in SYS_BASHRC.

> 
>  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.

No. There was already a way to do that: /etc/profile. The point of
SYS_BASHRC was to provide comparable functionality for interactive shells.

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

Yes, that's what system administrators were worried about, especially in an
environment with shared home directories and users logging into different
machines running different versions of Unix.

As to user choice, that's why it's not enabled by default. Like many
other things, it becomes the system admin's choice.

> 
> SYS_BASHRC narrows the use of bash from being a viable (interactive)
> language interpreter to just being a login shell. 

That's a little over-dramatic.


> Not everyone is an admin
> or user, some people are developers too, especially on debian :)

If you are a developer, you should be able to build a version of bash that
suits your needs.

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

If you do not like SYS_BASHRC, you may find it useful to open a bug report
with Debian and ask about their rationale for enabling it in their build.

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

I don't know. I don't think the bug-bash archives go back that far.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/