[SOLVED] "exec env -i" doesn't seem to work. What am I doing wrong?
Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
"exec env -i" doesn't seem to work. What am I doing wrong?
Section 4.4 of LFS 6.7 includes the following text -
Code:
Set up a good working environment by creating two new startup files for the bash shell. While logged in as user lfs,
issue the following command to create a new .bash_profile:
When logged on as user lfs, the initial shell is usually a login shell which reads the /etc/profile of the
host (probably containing some settings and environment variables) and then .bash_profile. The exec env
-i.../bin/bash command in the .bash_profile file replaces the running shell with a new one with a completely
empty environment, except for the HOME, TERM, and PS1 variables. This ensures that no unwanted and potentially
hazardous environment variables from the host system leak into the build environment. The technique used here
achieves the goal of ensuring a clean environment.
The problem is that after creating this file and starting a new logon shell as user lfs, and use "set" to list variables, I find that I still have all the host system variables set. The empty environment referred to doesn't happen.
It seems like the "exec env -i" command just isn't working.
After becoming user lfs I see 40 defined variables, if I remove .bash_profile I see 54 (.bashrc is present). Try removing .bash_profile, log in again and check the difference in the output of the set command (do remember to create .bash_profile again after testing).
If the problem still exists:
Quote:
after creating this file and starting a new logon shell as user lfs
Are you using su lfs or su - lfs? It should be the second one.
Thanks I think i've (kindof) figured it - it's something to do with "set" command. If I list variable with "env" then I get the results I would expect. Using "set" gives very strange results though. See below ('m starting from a newly opened shell (terminator, opened via openbox menu).
Hmm. As well as variables, set also returns a huge barrage of code after the variables when run from a login shell (I wont post it here as there's 8,700+ lines). I don't know if this is the proper behaviour?
I'm assuming that my x-launched terminal is not a login shell (though I thought these were login shells - you learn something every day).
The set command shows everything that is set during the login process and there are big differences in the amount of lines when counted. To give you an example: My LFS box has 109 lines total and my debian squeeze box has 8823 lines total when running set | wc -l.......
The outcome of the env command should be a lot closer together (LFS 42, Debian 38 on my boxes).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.