On 2020-06-20 21:24 -0500, Bruce Dubbs via lfs-dev wrote: > 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.
It's strange. I read bash code and commit history but found --norc should disable loading of SYS_BASHRC, since bash-2.0. It also really works on latest Arch (but it didn't work on Arch in Nov 2019). -- Xi Ruoyao <xry...@mengyan1223.wang> School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
