source: chapter04/settingenviron.xml@ a9fde34e

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE section [
  <!ENTITY % general-entities SYSTEM "../general.ent">
  %general-entities;
]>
<section xmlns="http://docbook.org/docbook-ng"
         xml:id="ch-tools-settingenviron">
<title>Setting up the environment</title>
<?dbhtml filename="settingenvironment.html"?>

<para>We're going to set up a good working environment by creating two new
startup files for the <command>bash</command> shell. While logged in as
user <emphasis>lfs</emphasis>, issue the following command to create a new
<filename>.bash_profile</filename>:</para>

<screen><userinput>cat &gt; ~/.bash_profile &lt;&lt; "EOF"
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
EOF</userinput></screen>

<para>Normally, when you log on as user <emphasis>lfs</emphasis>,
the initial shell is a <emphasis>login</emphasis> shell which reads the
<filename>/etc/profile</filename> of your host (probably containing some
settings of environment variables) and then <filename>.bash_profile</filename>.
The <command>exec env -i ... /bin/bash</command> command in the latter 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 our
build environment. The technique used here is a little strange, but it achieves
the goal of enforcing a clean environment.</para>

<para>The new instance of the shell is a <emphasis>non-login</emphasis> shell,
which doesn't read the <filename>/etc/profile</filename> or
<filename>.bash_profile</filename> files, but reads the
<filename>.bashrc</filename> file instead. Create this latter file now:</para>

<screen><userinput>cat &gt; ~/.bashrc &lt;&lt; "EOF"
set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
PATH=/tools/bin:/bin:/usr/bin
export LFS LC_ALL PATH
EOF</userinput></screen>

<para>The <command>set +h</command> command turns off
<command>bash</command>'s hash function. Normally hashing is a useful
feature: <command>bash</command> uses a hash table to remember the
full pathnames of executable files to avoid searching the PATH time and time
again to find the same executable. However, we'd like the new tools to be
used as soon as they are installed. By switching off the hash function, our
<quote>interactive</quote> commands (<command>make</command>,
<command>patch</command>, <command>sed</command>,
<command>cp</command> and so forth) will always use
the newest available version during the build process.</para>

<para>Setting the user file-creation mask to 022 ensures that newly created
files and directories are only writable for their owner, but readable and
executable for anyone.</para>

<para>The LFS variable should of course be set to the mount point you
chose.</para>

<para>The LC_ALL variable controls the localization of certain programs,
making their messages follow the conventions of a specified country. If your
host system uses a version of Glibc older than 2.2.4,
having LC_ALL set to something other than <quote>POSIX</quote> or
<quote>C</quote> during this chapter may cause trouble if you exit the chroot
environment and wish to return later.  By setting LC_ALL to <quote>POSIX</quote>
(or <quote>C</quote>, the two are equivalent) we ensure that
everything will work as expected in the chroot environment.</para>

<para>We prepend <filename class="directory">/tools/bin</filename> to the standard PATH so
that, as we move along through this chapter, the tools we build will get used
during the rest of the building process.</para>

<para>Finally, to have our environment fully prepared for building the
temporary tools, source the just-created profile:</para>

<screen><userinput>source ~/.bash_profile</userinput></screen>

</section>