On 2020-06-21 07:29 -0500, Bruce Dubbs via lfs-dev wrote: > On 6/21/20 5:33 AM, Xi Ruoyao via lfs-dev wrote: > > 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. > > > > What do you get with > > env -i bash --noprofile --init-file $HOME/.bash_profile
It loaded both $HOME/.bash_profile and /etc/bash.bashrc, but not $HOME/.bashrc. (I tested them with probes like `export DOT_BASH_PROFILE=1`.) > I'm also thinking that we ought to un-hide .bashrc and create lfs-bashrc. > > That is: > > cat > ~/.bash_profile << "EOF" > exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash --noprofile > --init-file $HOME/lfs-bashrc > EOF It would still load bash.bashrc. "--noprofile --login" will dismiss bash.bashrc. (Only tested on Ubuntu 18.04.) > Not tested as I don't have a commercial distro up at the moment. You can try https://distrotest.net, if your connection to it is fast enough. -- 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
