On 2020-06-21 18:22 +0800, Xi Ruoyao via lfs-dev wrote: > On 2020-06-21 05:16 -0500, Bruce Dubbs via lfs-dev wrote: > > On 6/21/20 12:57 AM, Xi Ruoyao via lfs-dev wrote: > > > On 2020-06-21 13:24 +0800, Xi Ruoyao via lfs-dev wrote: > > > > 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). > > > > > > Which distro are you using? I tried Arch (latest) and Ubuntu (18.04) on > > > my > > > laptops, and SUSE (leap 15.2) on distrotest.net. On all of these --norc > > > works > > > so maybe we can throw every environment variables into env command in > > > .bash_profile and use --norc. > > > > I was using the system installed by ubuntu-20.04-desktop-amd64.iso for > > testing. > > > > If you do 'env -i bash --norc' and then 'set', do you get all the bash > > completion macros? > > No. I tried: > > $ env -i PS1='(test shell)$ ' bash --norc > (test shell)$ env > > The output: > > PWD=/home/xry111 > SHLVL=1 > PS1=(test shell)$ > _=/usr/bin/env > > It seems very clean. But my test system is a Ubuntu 18.04. I'll try 20.04 > via > distrotest.net :).
Oh you mean "set", not "env". "set" prints many variables (including $SHELLOPTS). But all the variables are also there even if I rename /etc/bash.bashrc. -- 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
