Re: Avoid sourcing bashrc when connected to sockets

[Kerin Millar]

On Sun, 13 Feb 2022 11:55:55 -0800
Andrew Gregory <andrew.gregory.8@gmail.com> wrote:

> The pacman package manager runs install scripts by forking and invoking a
> compile-time configured shell by calling "<shell> -c '. <path-to-script>;
> <operation> <args>'", e.g. "bash -c '. /tmp/.INSTALL; pre_install pacman'".  A
> while back we switched from using pipes to sockets to communicate with the 
> fork
> in order to avoid SIGPIPE problems.  Unfortunately, this makes bash think it's
> being run under rsh/ssh and it now reads ~/.bashrc, which can break scripts.
> Can the rsh/ssh check be modified to ignore this case?  Or, if it can't (which

Not that I'm aware of.

> I assume is the case), what can we do to avoid this behavior in a way least
> likely to cause problems when pacman is compiled with a shell other than bash?

Assuming that you must continue to connect the standard input in this fashion, 
you could treat bash as a special case and supply the --norc option. You should 
also ensure that ENV is never defined in the shell's environment. Doing so will 
prevent bash from sourcing the value of ENV in the event that it is started in 
posix mode. Typically, that would happen as a result of executing /bin/sh in 
its capacity as a symlink to bash. Many other sh(1) implementations look for 
ENV too. Fortunately, there is no need to specify --norc in that particular 
case.

-- 
Kerin Millar