lfs-book/chapter07/profile.xml

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
  <!ENTITY % general-entities SYSTEM "../general.ent">
  %general-entities;
]>

<sect1 id="ch-scripts-profile">
  <?dbhtml filename="profile.html"?>

  <title>The Bash Shell Startup Files</title>

  <indexterm zone="ch-scripts-profile">
    <primary sortas="e-/etc/profile">/etc/profile</primary>
  </indexterm>

  <para>The shell program <command>/bin/bash</command> (hereafter referred to
  as <quote>the shell</quote>) uses a collection of startup files to help
  create an environment to run in. Each file has a specific use and may affect
  login and interactive environments differently. The files in the <filename
  class="directory">/etc</filename> directory provide global settings. If an
  equivalent file exists in the home directory, it may override the global
  settings.</para>

  <para>An interactive login shell is started after a successful login, using
  <command>/bin/login</command>, by reading the <filename>/etc/passwd</filename>
  file. An interactive non-login shell is started at the command-line (e.g.,
  <prompt>[prompt]$</prompt><command>/bin/bash</command>). A non-interactive
  shell is usually present when a shell script is running. It is non-interactive
  because it is processing a script and not waiting for user input between
  commands.</para>

  <para>For more information, see <command>info bash</command> under the
  <emphasis>Bash Startup Files and Interactive Shells</emphasis> section.</para>

  <para>The files <filename>/etc/profile</filename> and
  <filename>~/.bash_profile</filename> are read when the shell is
  invoked as an interactive login shell.</para>

  <para>The base <filename>/etc/profile</filename> below sets some
  environment variables necessary for native language support. Setting
  them properly results in:</para>

  <itemizedlist>
    <listitem>
      <para>The output of programs translated into the native language</para>
    </listitem>
    <listitem>
      <para>Correct classification of characters into letters, digits and other
      classes. This is necessary for <command>bash</command> to properly accept
      non-ASCII characters in command lines in non-English locales</para>
    </listitem>
    <listitem>
      <para>The correct alphabetical sorting order for the country</para>
    </listitem>
    <listitem>
      <para>Appropriate default paper size</para>
    </listitem>
    <listitem>
      <para>Correct formatting of monetary, time, and date values</para>
    </listitem>
  </itemizedlist>

  <para>This script also sets the <envar>INPUTRC</envar> environment variable that
  makes Bash and Readline use the <filename>/etc/inputrc</filename> file created
  earlier.</para>

  <para>Replace <replaceable>[ll]</replaceable> below with the two-letter code
  for the desired language (e.g., <quote>en</quote>) and
  <replaceable>[CC]</replaceable> with the two-letter code for the appropriate
  country (e.g., <quote>GB</quote>). <replaceable>[charmap]</replaceable> should
  be replaced with the canonical charmap for your chosen locale. Optional
  modifiers such as <quote>@euro</quote> may also be present.</para>

  <para>The list of all locales supported by Glibc can be obtained by running
  the following command:</para>

<screen role="nodump"><userinput>locale -a</userinput></screen>

  <para>Charmaps can have a number of aliases, e.g., <quote>ISO-8859-1</quote>
  is also referred to as <quote>iso8859-1</quote> and <quote>iso88591</quote>.
  Some applications cannot handle the various synonyms correctly (e.g., require
  that <quote>UTF-8</quote> is written as <quote>UTF-8</quote>, not
  <quote>utf8</quote>), so it is safest in most
  cases to choose the canonical name for a particular locale. To determine
  the canonical name, run the following command, where <replaceable>[locale
  name]</replaceable> is the output given by <command>locale -a</command> for
  your preferred locale (<quote>en_GB.iso88591</quote> in our example).</para>

<screen role="nodump"><userinput>LC_ALL=<replaceable>[locale name]</replaceable> locale charmap</userinput></screen>

  <para>For the <quote>en_GB.iso88591</quote> locale, the above command
  will print:</para>

<screen><computeroutput>ISO-8859-1</computeroutput></screen>

  <para>This results in a final locale setting of <quote>en_GB.ISO-8859-1</quote>.
  It is important that the locale found using the heuristic above is tested prior
  to it being added to the Bash startup files:</para>

<screen role="nodump"><userinput>LC_ALL=[locale name] locale country
LC_ALL=[locale name] locale language
LC_ALL=[locale name] locale charmap
LC_ALL=[locale name] locale int_curr_symbol
LC_ALL=[locale name] locale int_prefix</userinput></screen>

  <para>The above commands should print the country and language names, the
  character encoding used by the locale, the local currency and the prefix to dial
  before the telephone number in order to get into the country. If any of the
  commands above fail with a message similar to the one shown below, this means
  that your locale was either not installed in Chapter 6 or is not supported by
  the default installation of Glibc.</para>

<screen><computeroutput>locale: Cannot set LC_* to default locale: No such file or directory</computeroutput></screen>

  <para>If this happens, you should either install the desired locale using the
  <command>localedef</command> command, or consider choosing a different locale.
  Further instructions assume that there are no such error messages from
  Glibc.</para>

  <!-- FIXME: the xlib example will became obsolete real soon -->
  <para>Some packages beyond LFS may also lack support for your chosen locale. One
  example is the X library (part of the X Window System), which outputs the
  following error message:</para>

<screen><computeroutput>Warning: locale not supported by Xlib, locale set to C</computeroutput></screen>

  <para>Sometimes it is possible to fix this by removing the charmap part of the
  locale specification, as long as that does not change the character map that
  Glibc associates with the locale (this can be checked by running the
  <command>locale charmap</command> command in both locales).  For example, one
  would have to change &quot;de_DE.ISO-8859-15@euro&quot; to
  &quot;de_DE@euro&quot; in order to get this locale recognized by Xlib.</para>

  <para>Other packages can also function incorrectly (but may not necessarily
  display any error messages) if the locale name does not meet their expectations.
  In those cases, investigating how other Linux distributions support your locale
  might provide some useful information.</para>

  <para>Once the proper locale settings have been determined, create the
  <filename>/etc/profile</filename> file:</para>

<screen><userinput>cat &gt; /etc/profile &lt;&lt; "EOF"
<literal># Begin /etc/profile

export LANG=<replaceable>[ll]</replaceable>_<replaceable>[CC]</replaceable>.<replaceable>[charmap]</replaceable><replaceable>[@modifiers]</replaceable>
export INPUTRC=/etc/inputrc

# End /etc/profile</literal>
EOF</userinput></screen>

  <para>The <quote>C</quote> (default) and <quote>en_US</quote> (the recommended
  one for United States English users) locales are different. <quote>C</quote>
  uses the US-ASCII 7-bit character set, and treats bytes with the high bit set
  as invalid characters. That's why, e.g., the <command>ls</command> command
  substitutes them with question marks in that locale. Also, an attempt to send
  mail with such characters from Mutt or Pine results in non-RFC-conforming
  messages being sent (the charset in the outgoing mail is indicated as <quote>unknown
  8-bit</quote>). So you can use the <quote>C</quote> locale only if you are sure that
  you will never need 8-bit characters.</para>

  <para>UTF-8 based locales are not supported well by many programs. E.g., the
  <command>watch</command> program displays only ASCII characters in UTF-8
  locales and has no such restriction in traditional 8-bit locales like en_US.
  Without patches and/or installing software beyond BLFS, in UTF-8 based locales
  you will not be able to do such basic tasks as printing plain-text files from
  the command line, recording Windows-readable CDs with filenames containing
  non-ASCII characters, viewing ID3v1 tags in MP3 files and so on. Work is in
  progress to document and, if possible, fix such problems, see
  <ulink url="&blfs-root;view/svn/introduction/locale-issues.html"/>.
  It is, however, safe to use UTF-8 based locales if you are going to use only
  KDE or GNOME and never open the terminal.</para>
  <!-- All abovementioned problems except "watch" have a known fix beyond BLFS -->

</sect1>