On 6/20/20 8:30 PM, Bruce Dubbs wrote:
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.
I tested several options. That /etc/bash.bashrc thing is evil. I
edited it to put at the top: echo "IN /etc/bash.bashrc"
Even with your line
exec env -i ENV=$HOME/lfs-bashrc HOME=$HOME TERM=$TERM PS1='\u:\w\$ '
/bin/bash --posix
(Note that I changed the file name to make it a non-hidden file.)
it STILL runs bash.bashrc. --norc doesn't change that either. Nor does
--init-file $HOME/lfs-bashrc
In the case if ubuntu though the posix setting does not install the
function command_not_found_handle, but I don't think we can really count
on that.
Really the I think the only way to handle this is to edit
/etc/bash.bashrc to put a return in on the first line or to rename the
file and let the user restore it if desired later.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
