On 6/20/20 7:07 PM, Xi Ruoyao via lfs-dev wrote:
On 2020-06-20 16:58 -0500, Bruce Dubbs via lfs-dev wrote:
On 6/20/20 2:42 PM, Xi Ruoyao via lfs-dev wrote:
The discussion with Frans de Boer in lfs-support shown that the environment
variables from host can catch us completely off guard. Though in his case
the
problem is that he forgot to create /home/lfs/.bash_profile, normally
/etc/bash.bashrc would be more dangerous (the book has no consideration of
this
file), and used by many distros.
So if there is no objection I'll commit the change we've discussed in last
Nov.:
/home/lfs/.bash_profile:
exec env -i ENV=$HOME/.lfs_bashrc \
HOME=$HOME \
TERM=$TERM \
PS1='\u:\w\$ ' \
/bin/bash --posix
/home/lfs/.lfs_bashrc:
set +o posix
set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
LFS_TGT=$(uname -m)-lfs-linux-gnu
PATH=/usr/bin
if [ ! -L /bin ]; then PATH=/bin:$PATH; fi
PATH=$LFS/tools/bin:$PATH
export LFS LC_ALL LFS_TGT PATH
So the --posix in .bash_profile allows the use of
ENV=$HOME/.lfs_bashrc and then the first line in .lfs_bashrc turns posix
mode off?
At a minimum this looks like a hack that needs a fair amount of explanation.
The reason for this is because a user forgot to create .bash_profile?
In that case the above doesn't work.
The discussion just proved that environment variables from host are really
harmful.
From https://sources.debian.org/src/bash/5.0-6/debian/README/
5. What is /etc/bash.bashrc? It doesn't seem to be documented.
The Debian version of bash is compiled with a special option
(-DSYS_BASHRC) that makes bash read /etc/bash.bashrc before ~/.bashrc
for interactive non-login shells. So, on Debian systems,
/etc/bash.bashrc is to ~/.bashrc as /etc/profile is to
~/.bash_profile.
When I look at a debian system's /etc/bash.bashrc, I don't see what
would affect what we have now. What was the reported problem?
We've been using the current structure for a long time without a
reported issue. What's new?
I studied OpenSUSE bash.bashrc a little. It's a giant monster script (even
sourcing some scripts from /etc/profile.d) so I won't be suprised if one day a
bash.bashrc breaks some package.
And after a sleep I realized a more serious issue: if some distro has a
/usr/share/config.site (or /usr/etc/config.site, which is not FHS and shouldn't
exist), it would be used by autotools configure script *even if we are cross
compiling*, and break temporary glibc build. Perhaps we should "export
CONFIG_SITE=/dev/null" in /home/lfs/.bashrc to override it.
I wrote the above before I saw the messages in -support. I do note that
in my debian system I used to get LFS up on my new system I edited
/etc/bash.bashrc so the first line was 'return'. I did that primarily
because I don't like polluting the environment with bash completion stuff.
I think the problem is not 'exec env ... /bin/bash' directly, but the
changes to bash invocation by some distros.
I wonder if 'exec env ... /bin/bash --init-file ~/.bashrc' would work.
I'll do a test of that.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
