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.
to set up clean environment if that script is only executed when I log into the system.I mean, every time I open new shell in terminal emulator, ENV variables will be created from the system-wide bash configuration files, so, what's the point? Wouldn't it be better if that code is in bashrc ?
type exec is a shell built-in for bash. From the bash man page,
Code:
SHELL BUILTIN COMMANDS
...
exec [-cl] [-a name] [command [arguments]]
If command is specified, it replaces the shell. No new process
is created. The arguments become the arguments to command. If
the -l option is supplied, the shell places a dash at the beginā
ning of the zeroth argument passed to command. This is what
login(1) does. The -c option causes command to be executed with
an empty environment. If -a is supplied, the shell passes name
as the zeroth argument to the executed command. If command canā
not be executed for some reason, a non-interactive shell exits,
unless the shell option execfail is enabled, in which case it
returns failure. An interactive shell returns failure if the
file cannot be executed. If command is not specified, any rediā
rections take effect in the current shell, and the return status
is 0. If there is a redirection error, the return status is 1.
...
type env is /bin/env in my system. From the env man page for the -i option.
Code:
NAME
env - run a program in a modified environment
SYNOPSIS
env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]
...
-i, --ignore-environment
start with an empty environment
...
Explanation
The TERM and HOME environment variables are specified because a new empty environment will be created without those variables. Therefore they should be set using the current environment variables.
Why is it doing that?
Essentially what it is doing is setting the format for how the environment is displayed for the user. For instance when user sam logs in then his environment would look like the following.
Code:
sam:~$
For instance on my system my PS1="[\u@\h \W]\$ " therefore my environment looks like the following (note sam is my user and stealth is my hostname).
Code:
[sam@stealth ~]$
It's just a bit of voo-doo magic to get the format of the prompt to display however the user wishes. Other than that it doesn't serve much purpose.
type exec is a shell built-in for bash. From the bash man page,
Code:
SHELL BUILTIN COMMANDS
...
exec [-cl] [-a name] [command [arguments]]
If command is specified, it replaces the shell. No new process
is created. The arguments become the arguments to command. If
the -l option is supplied, the shell places a dash at the beginā
ning of the zeroth argument passed to command. This is what
login(1) does. The -c option causes command to be executed with
an empty environment. If -a is supplied, the shell passes name
as the zeroth argument to the executed command. If command canā
not be executed for some reason, a non-interactive shell exits,
unless the shell option execfail is enabled, in which case it
returns failure. An interactive shell returns failure if the
file cannot be executed. If command is not specified, any rediā
rections take effect in the current shell, and the return status
is 0. If there is a redirection error, the return status is 1.
...
type env is /bin/env in my system. From the env man page for the -i option.
Code:
NAME
env - run a program in a modified environment
SYNOPSIS
env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]
...
-i, --ignore-environment
start with an empty environment
...
Explanation
The TERM and HOME environment variables are specified because a new empty environment will be created without those variables. Therefore they should be set using the current environment variables.
Why is it doing that?
Essentially what it is doing is setting the format for how the environment is displayed for the user. For instance when user sam logs in then his environment would look like the following.
Code:
sam:~$
For instance on my system my PS1="[\u@\h \W]\$ " therefore my environment looks like the following (note sam is my user and stealth is my hostname).
Code:
[sam@stealth ~]$
It's just a bit of voo-doo magic to get the format of the prompt to display however the user wishes. Other than that it doesn't serve much purpose.
SAM
Hi Sam,
thank you for trying to explain these thing to me.
I perfectly understand what you say, but my real question is this - Yes, I will start with clean environment after log in, HOWEVER, environment will be clean as long as I don't start new non-login shell.In that new shell, environment variables will be set from some other configuration file(not sure where from), so that kind of defeat the purpose of bash_profile script.For example, when I log in, and then start new shell where I will build the system, I get this env vars set(my host system is ubuntu)
to set up clean environment if that script is only executed when I log into the system.
I mean, every time I open new shell in terminal emulator, ENV variables will be created from the system-wide bash configuration files, so, what's the point? Wouldn't it be better if that code is in bashrc ?
This specific ~/.bash_profile is executed when you log in as user lfs (i.e.: su - lfs)
Quote:
When bash is invoked as an interactive login shell, or as a non-inter‐
active shell with the --login option, it first reads and executes com‐
mands from the file /etc/profile, if that file exists. After reading
that file, it looks for ~/.bash_profile
So after you issue su - lfs, /etc/profile is parsed first and then ~/.bash_profile. Because .bash_profile contains exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash, all that is set by /etc/profile is removed (the env -i part and a few basic things are set (HOME, TERM and PS1). The exec line ends with /bin/bash, which starts a non-login shell and .bashrc is read, which sets a few other environment variables. This process ensures a clean environment.
You do need to use su - lfs and not su lfs!!The latter will start a none login shell that does not read ~/.bash_profile, it reads ~/.bashrc and thus doesn't clean the environment.
This specific ~/.bash_profile is executed when you log in as user lfs (i.e.: su - lfs)
So after you issue su - lfs, /etc/profile is parsed first and then ~/.bash_profile. Because .bash_profile contains exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash, all that is set by /etc/profile is removed (the env -i part and a few basic things are set (HOME, TERM and PS1). The exec line ends with /bin/bash, which starts a non-login shell and .bashrc is read, which sets a few other environment variables. This process ensures a clean environment.
You do need to use su - lfs and not su lfs!!The latter will start a none login shell that does not read ~/.bash_profile, it reads ~/.bashrc and thus doesn't clean the environment.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.