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
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
Not tested as I don't have a commercial distro up at the moment.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
