r6364 - in trunk/BOOK: . general/sysutils introduction/important introduction/welcome postlfs/editors

dnicholson at linuxfromscratch.org dnicholson at linuxfromscratch.org
Sat Oct 28 00:13:20 PDT 2006


Author: dnicholson
Date: 2006-10-28 01:13:18 -0600 (Sat, 28 Oct 2006)
New Revision: 6364

Modified:
   trunk/BOOK/general.ent
   trunk/BOOK/general/sysutils/mc.xml
   trunk/BOOK/general/sysutils/unzip.xml
   trunk/BOOK/introduction/important/locale-issues.xml
   trunk/BOOK/introduction/welcome/changelog.xml
   trunk/BOOK/postlfs/editors/nano.xml
Log:
Implemented Alexander Patrakov's Locale Related Issues changes


Modified: trunk/BOOK/general/sysutils/mc.xml
===================================================================
--- trunk/BOOK/general/sysutils/mc.xml	2006-10-27 23:32:24 UTC (rev 6363)
+++ trunk/BOOK/general/sysutils/mc.xml	2006-10-28 07:13:18 UTC (rev 6364)
@@ -36,10 +36,14 @@
     full power of the command prompt.</para>
 
     <caution>
-      <para>The <application>MC</application> package has some issues when
-      used in a UTF-8 based locale. For a full explanation of the issues, see
-      the <xref linkend="locale-mc"/> section of the
-      <xref linkend="locale-issues"/>.</para>
+      <para>The <application>MC</application> package has major issues when
+      used in a UTF-8 based locale because it assumes the characters are
+      always one byte wide.  See <ulink url="&files-anduin;/mc-bad.png">this
+      screenshot</ulink> (taken in a ru_RU.UTF-8 locale).
+      See the <ulink url="&blfs-wiki;/MC">MC Wiki</ulink> page for a way
+      to work around these problems.
+      For a general discussion of these types of issues, see
+      the <xref linkend="locale-issues"/> page.</para>
     </caution>
 
     <bridgehead renderas="sect3">Package Information</bridgehead>

Modified: trunk/BOOK/general/sysutils/unzip.xml
===================================================================
--- trunk/BOOK/general/sysutils/unzip.xml	2006-10-27 23:32:24 UTC (rev 6363)
+++ trunk/BOOK/general/sysutils/unzip.xml	2006-10-28 07:13:18 UTC (rev 6364)
@@ -38,9 +38,10 @@
 
     <caution>
       <para>The <application>UnZip</application> package has some locale
-      related issues. For a full explanation of the issues and some possible
-      solutions, see the <xref linkend="locale-unzip"/> section of the
-      <xref linkend="locale-issues"/>.</para>
+      related issues. See the discussion below in the
+      <xref linkend="unzip-locale-issues"/> section. A more general
+      discussion of these problems can be found on the
+      <xref linkend="locale-issues"/> page.</para>
     </caution>
 
     <bridgehead renderas="sect3">Package Information</bridgehead>
@@ -70,6 +71,80 @@
 
   </sect2>
 
+  <sect2 id="unzip-locale-issues">
+    <title>UnZip Locale Issues</title>
+
+    <note>
+      <para>Use of <application>UnZip</application> in the
+      <application>JDK</application>, <application>Mozilla</application>,
+      <application>DocBook</application> or any other BLFS package
+      installation is not a problem, as BLFS instructions never use
+      <application>UnZip</application> to extract a file with non-ASCII
+      characters in the file's name.</para>
+    </note>
+
+    <para>The <application>UnZip</application> package assumes that filenames
+    stored in the ZIP archives created on non-Unix systems are encoded in
+    CP850, and that they should be converted to ISO-8859-1 when writing files
+    onto the filesystem. Such assumptions are not always valid. In fact,
+    inside the ZIP archive, filenames are encoded in the DOS codepage that is
+    in use in the relevant country, and the filenames on disk should be in
+    the locale encoding. In MS Windows, the OemToChar() C function (from
+    <filename>User32.DLL</filename>) does the correct conversion (which is
+    indeed the conversion from CP850 to a superset of ISO-8859-1 if MS
+    Windows is set up to use the US English language), but there is no
+    equivalent in Linux.</para>
+
+    <para>When using <command>unzip</command> to unpack a ZIP archive
+    containing non-ASCII filenames, the filenames are damaged because
+    <command>unzip</command> uses improper conversion when any of its
+    encoding assumptions are incorrect. For example, in the ru_RU.KOI8-R
+    locale, conversion of filenames from CP866 to KOI8-R is required, but
+    conversion from CP850 to ISO-8859-1 is done, which produces filenames
+    consisting of undecipherable characters instead of words (the closest
+    equivalent understandable example for English-only users is rot13). There
+    are several ways around this limitation:</para>
+
+    <para>1) For unpacking ZIP archives with filenames containing non-ASCII
+    characters, use <ulink url="http://www.winzip.com/">WinZip</ulink> while-      running the <ulink url="http://www.winehq.com/">Wine</ulink> Windows
+    emulator.</para>
+
+    <para>2) After running <command>unzip</command>, fix the damage made to
+    the filenames using the <command>convmv</command> tool
+    (<ulink url="http://j3e.de/linux/convmv/"/>). The following is an example
+    for the ru_RU.KOI8-R locale:</para>
+
+    <blockquote>
+      <para>Step 1. Undo the conversion done by
+      <command>unzip</command>:</para>
+
+<screen><userinput>convmv -f iso-8859-1 -t cp850 -r --nosmart --notest \
+    <replaceable></path/to/unzipped/files></replaceable></userinput></screen>
+
+      <para>Step 2. Do the correct conversion instead:</para>
+
+<screen><userinput>convmv -f cp866 -t koi8-r -r --nosmart --notest \
+    <replaceable></path/to/unzipped/files></replaceable></userinput></screen>
+    </blockquote>
+
+    <para>3) Apply this patch to unzip:
+    <ulink url="https://bugzilla.altlinux.ru/attachment.cgi?id=532"/></para>
+
+    <para>It allows to specify the assumed filename encoding in the ZIP
+    archive using the <option>-O charset_name</option> option and the
+    on-disk filename encoding using the <option>-I charset_name</option>
+    option. Defaults: the on-disk filename encoding is the locale encoding,
+    the encoding inside the ZIP archive is guessed according to the builtin
+    table based on the locale encoding. For US English users, this still
+    means that unzip converts from CP850 to ISO-8859-1 by default.</para>
+
+    <para>Caveat: this method works only with 8-bit locale encodings, not
+    with UTF-8. Attempting to use a patched <command>unzip</command> in UTF-8
+    locales may result in a segmentation fault and is probably a security
+    risk.</para>
+
+  </sect2>
+
   <sect2 role="installation">
     <title>Installation of UnZip</title>
 

Modified: trunk/BOOK/general.ent
===================================================================
--- trunk/BOOK/general.ent	2006-10-27 23:32:24 UTC (rev 6363)
+++ trunk/BOOK/general.ent	2006-10-28 07:13:18 UTC (rev 6364)
@@ -1,4 +1,4 @@
-<!ENTITY day          "27">                   <!-- Always 2 digits -->
+<!ENTITY day          "28">                   <!-- Always 2 digits -->
 <!ENTITY month        "10">                   <!-- Always 2 digits -->
 <!ENTITY year         "2006">
 <!ENTITY version      "svn-&year;&month;&day;">

Modified: trunk/BOOK/introduction/important/locale-issues.xml
===================================================================
--- trunk/BOOK/introduction/important/locale-issues.xml	2006-10-27 23:32:24 UTC (rev 6363)
+++ trunk/BOOK/introduction/important/locale-issues.xml	2006-10-28 07:13:18 UTC (rev 6364)
@@ -16,145 +16,234 @@
   <title>Locale Related Issues</title>
 
   <para>This page contains information about locale related problems and
-  issues. In this paragraph you'll find a generic overview of things that can
-  come up when configuring your system for various locales. The previous
-  sentence and the remainder of this paragraph must still be
-  revised/completed.</para>
+  issues. In the following paragraphs you'll find a generic overview of
+  things that can come up when configuring your system for various locales.
+  Many (but not all) existing locale-related problems can be classified
+  and fall under one of the headings below. The severity ratings below use
+  the following criteria:</para>
 
- <sect2>
+  <itemizedlist>
+    <listitem>
+      <para>Critical: The program doesn't perform its main function.
+      The fix would be very intrusive, it's better to search for a
+      replacement.</para>
+    </listitem>
+    <listitem>
+      <para>High: Part of the functionality that the program provides
+      is not usable. If that functionality is required, it's better to
+      search for a replacement.</para>
+    </listitem>
+    <listitem>
+      <para>Low: The program works in all typical use cases, but lacks
+      some functionality normally provided by its equivalents.</para>
+    </listitem>
+  </itemizedlist>
 
-    <title>Package Specific Locale Issues</title>
+  <para>If there is a known workaround for a specific package, it will
+  appear on that package's page.</para>
 
-    <para>For package-specific issues, find the concerned package from the list
-    below and follow the link to view the available information. If a package
-    is not listed here, it does not mean there are no known locale-specific
-    issues or problems with that package. It only means that this page has not
-    been updated with the locale-specific information regarding that package.
-    Please reference the BLFS Wiki page for a particular package for any
-    additional locale-specific information. </para>
+  <sect2 id="locale-not-valid-option"
+         xreflabel="Needed Encoding Not a Valid Option">
 
-    <itemizedlist>
+    <title>The Needed Encoding is Not a Valid Option in the Program</title>
 
-      <title>List of Packages with Locale Related Issues</title>
+    <para>Severity: Critical</para>
 
-      <listitem>
-        <para><xref linkend="locale-mc"/></para>
-      </listitem>
-      <listitem>
-        <para><xref linkend="locale-unzip"/></para>
-      </listitem>
-      <listitem>
-        <para><xref linkend="locale-nano"/></para>
-      </listitem>
+    <para>Some programs require the user to specify the character encoding
+    for their input or output data and present only a limited choice of
+    encodings. This is the case for the <option>-X</option> option in
+    <xref linkend="a2ps"/> and <xref linkend="enscript"/>,
+    the <option>-input-charset</option> option in unpatched
+    <xref linkend="cdrtools"/>, and the character sets offered for display
+    in the menu of <xref linkend="links"/>. If the required encoding is not
+    in the list, the program usually becomes completely unusable. For
+    non-interactive programs, it may be possible to work around this by
+    converting the document to a supported input character set before
+    submitting to the program.</para>
 
-    </itemizedlist>
+    <para>A solution to this type of problem is to implement the necessary
+    support for the missing encoding as a patch to the original program
+    (as done for <xref linkend="cdrtools"/> in this book), or to find a
+    replacement.</para>
 
-    <sect3 id="locale-mc" xreflabel="MC-&mc-version;">
+  </sect2>
 
-      <title><xref linkend="mc"/></title>
+  <sect2 id="locale-assumed-encoding"
+         xreflabel="Program Assumes Encoding">
 
-      <para>This package makes the assumption that <quote>characters</quote>
-      and <quote>bytes</quote> are the same thing. This is not true in UTF-8
-      based locales. Due to this assumption <application>MC</application> will
-      incorrectly position characters on the screen. After the cursor is moved
-      a bit the screen becomes totally unreadable, as illustrated on
-      <ulink url="&files-anduin;/mc-bad.png">this
-      screenshot</ulink> (taken in a ru_RU.UTF-8 locale). Additionally, input
-      of non-ASCII characters in the editor is impossible, even after selecting
-      <quote>Other 8-bit</quote> encoding from the menu.</para>
+    <title>The Program Assumes the Locale-Based Encoding of External
+    Documents</title>
 
-    </sect3>
+    <para>Severity: High for non-text documents, low for text
+    documents</para>
 
-    <sect3 id="locale-unzip" xreflabel="UnZip-&unzip-version;">
+    <para>Some programs, <xref linkend="nano"/> or
+    <xref linkend="joe"/> for example, assume that documents are always
+    in the encoding implied by the current locale. While this assumption
+    may be valid for the user-created documents, it is not safe for
+    external ones. When this assumption fails, non-ASCII characters are
+    displayed incorrectly, and the document may become unreadable.</para>
 
-      <title><xref linkend="unzip"/></title>
+    <para>If the external document is entirely text based, it can be
+    converted to the current locale encoding using the
+    <command>iconv</command> program.</para>
 
-      <note>
-        <para>Use of <application>UnZip</application> in the
-        <application>JDK</application>, <application>Mozilla</application>,
-        <application>DocBook</application> or any other BLFS package
-        installation is not a problem, as BLFS instructions never use
-        <application>UnZip</application> to extract a file with non-ASCII
-        characters in the file's name.</para>
-      </note>
+    <para>For documents that are not text-based, this is not possible.
+    In fact, the assumption made in the program may be completely
+    invalid for documents where the Microsoft Windows operating system
+    has set de facto standards. An example of this problem is ID3v1 tags
+    in MP3 files (see <ulink url="&blfs-wiki;/ID3v1Coding">this page</ulink>
+    for more details). For these cases, the only solution is to find a
+    replacement program that doesn't have the issue (e.g., one that
+    will allow you to specify the assumed document encoding).</para>
 
-      <para>The <application>UnZip</application> package assumes that filenames
-      stored in the ZIP archives created on non-Unix systems are encoded in
-      CP850, and that they should be converted to ISO-8859-1 when writing files
-      onto the filesystem. Such assumptions are not always valid. In fact,
-      inside the ZIP archive, filenames are encoded in the DOS codepage that is
-      in use in the relevant country, and the filenames on disk should be in
-      the locale encoding. In MS Windows, the OemToChar() C function (from
-      <filename>User32.DLL</filename>) does the correct conversion (which is
-      indeed the conversion from CP850 to a superset of ISO-8859-1 if MS
-      Windows is set up to use the US English language), but there is no
-      equivalent in Linux.</para>
+    <para>Among BLFS packages, this problem applies to
+    <xref linkend="nano"/>, <xref linkend="joe"/>, and all media players
+    except <xref linkend="audacious"/>.</para>
 
-      <para>When using <command>unzip</command> to unpack a ZIP archive
-      containing non-ASCII filenames, the filenames are damaged because
-      <command>unzip</command> uses improper conversion when any of its
-      encoding assumptions are incorrect. For example, in the ru_RU.KOI8-R
-      locale, conversion of filenames from CP866 to KOI8-R is required, but
-      conversion from CP850 to ISO-8859-1 is done, which produces filenames
-      consisting of undecipherable characters instead of words (the closest
-      equivalent understandable example for English-only users is rot13). There
-      are several ways around this limitation:</para>
+    <para>Another problem in this category is when someone cannot read
+    the documents you've sent them because their operating system is
+    set up to handle character encodings differently. This can happen
+    often when the other person is using Microsoft Windows, which only
+    provides one character encoding for a given country. For example,
+    this causes problems with UTF-8 encoded TeX documents created in
+    Linux. On Windows, most applications will assume that these documents
+    have been created using the default Windows 8-bit encoding. See the
+    <ulink url="&blfs-wiki;/tetex">teTeX</ulink> Wiki page for more
+    details.</para>
 
-      <para>1) For unpacking ZIP archives with filenames containing non-ASCII
-      characters, use <ulink url="http://www.winzip.com/">WinZip</ulink> while
-      running the <ulink url="http://www.winehq.com/">Wine</ulink> Windows
-      emulator.</para>
+    <para>In extreme cases, Windows encoding compatibility issues may be 
+    solved only by running Windows programs under
+    <ulink url="http://www.winehq.com/">Wine</ulink>.</para>
 
-      <para>2) After running <command>unzip</command>, fix the damage made to
-      the filenames using the <command>convmv</command> tool
-      (<ulink url="http://j3e.de/linux/convmv/"/>). The following is an example
-      for the ru_RU.KOI8-R locale:</para>
+  </sect2>
 
-      <blockquote>
-        <para>Step 1. Undo the conversion done by
-        <command>unzip</command>:</para>
+  <sect2 id="locale-wrong-filename-encoding"
+         xreflabel="Wrong Filename Encoding">
 
-<screen><userinput>convmv -f iso-8859-1 -t cp850 -r --nosmart --notest \
-    <replaceable></path/to/unzipped/files></replaceable></userinput></screen>
+    <title>The Program Uses or Creates Filenames in the Wrong Encoding</title>
 
-        <para>Step 2. Do the correct conversion instead:</para>
+    <para>Severity: Critical</para>
 
-<screen><userinput>convmv -f cp866 -t koi8-r -r --nosmart --notest \
-    <replaceable></path/to/unzipped/files></replaceable></userinput></screen>
-      </blockquote>
+    <para>The POSIX standard mandates that the filename encoding is
+    the encoding implied by the current LC_CTYPE locale category. This
+    information is well-hidden on the page which specifies the behavior
+    of <application>Tar</application> and <application>Cpio</application>
+    programs. Some programs get it wrong by default (or simply don't 
+    have enough information to get it right). The result is that they
+    create filenames which are not subsequently shown correctly by
+    <command>ls</command>, or they refuse to accept filenames that
+    <command>ls</command> shows properly. For the <xref linkend="glib2"/>
+    library, the problem can be corrected by setting the
+    <envar>G_FILENAME_ENCODING</envar> environment variable to the special
+    "@locale" value. <application>Glib2</application> based programs that
+    don't respect that environment variable are buggy.</para>
 
-      <para>3) Apply this patch to unzip:
-      <ulink url="https://bugzilla.altlinux.ru/attachment.cgi?id=532"/></para>
+    <para>The <xref linkend="zip"/>, <xref linkend="unzip"/>, and
+    <xref linkend="nautilus-cd-burner"/> have this problem because
+    they hard-code the expected filename encoding.
+    <application>UnZip</application> contains a hard-coded conversion
+    table between the CP850 (DOS) and ISO-8859-1 (UNIX) encodings and
+    uses this table when extracting archives created under DOS or
+    Microsoft Windows. However, this assumption only works for those
+    in the US and not for anyone using a UTF-8 locale. Non-ASCII
+    characters will be mangled in the extracted filenames.</para>
 
-      <para>It allows to specify the assumed filename encoding in the ZIP
-      archive using the <option>-O charset_name</option> option and the
-      on-disk filename encoding using the <option>-I charset_name</option>
-      option. Defaults: the on-disk filename encoding is the locale encoding,
-      the encoding inside the ZIP archive is guessed according to the builtin
-      table based on the locale encoding. For US English users, this still
-      means that unzip converts from CP850 to ISO-8859-1 by default.</para>
+    <para>On the other hand,
+    <application>Nautilus CD Burner</application> checks names of
+    files added to its window for UTF-8 validity. This is wrong for
+    users of non-UTF-8 locales. Also,
+    <application>Nautilus CD Burner</application> unconditionally
+    calls <command>mkisofs</command> with the
+    <parameter>-input-charset UTF-8</parameter> parameter, which is
+    only correct in UTF-8 locales.</para>
 
-      <para>Caveat: this method works only with 8-bit locale encodings, not
-      with UTF-8. Attempting to use a patched <command>unzip</command> in UTF-8
-      locales may result in a segmentation fault and is probably a security
-      risk.</para>
+    <para>The general rule for avoiding this class of problems is to 
+    avoid installing broken programs. If this is impossible, the
+    <ulink url="http://j3e.de/linux/convmv/">convmv</ulink>
+    command-line tool can be used to fix filenames created by these
+    broken programs, or intentionally mangle the existing filenames
+    to meet the broken expectations of such programs.</para>
 
-    </sect3>
+    <para>In other cases, a similar problem is caused by importing
+    filenames from a system using a different locale with a tool that
+    is not locale-aware (e.g., <xref linkend="nfs-utils"/> or
+    <xref linkend="openssh"/>). In order to avoid mangling non-ASCII 
+    characters when transferring files to a system with a different
+    locale, any of the following methods can be used:</para>
 
-    <sect3 id="locale-nano" xreflabel="Nano-&nano-version;">
+    <itemizedlist>
+      <listitem>
+        <para>Transfer anyway, fix the damage with
+        <command>convmv</command>.</para>
+      </listitem>
+      <listitem>
+        <para>On the sending side, create a tar archive with the 
+        <parameter>--format=posix</parameter> switch passed to
+        <command>tar</command> (this will be the default in a future 
+        version of <command>tar</command>).</para>
+      </listitem>
+      <listitem>
+        <para>Mail the files as attachments. Mail clients specify the
+        encoding of attached filenames.</para>
+      </listitem>
+      <listitem>
+        <para>Write the files to a removable disk formatted with a FAT or
+        FAT32 filesystem.</para>
+      </listitem>
+      <listitem>
+        <para>Transfer the files using Samba.</para>
+      </listitem>
+      <listitem>
+        <para>Transfer the files via FTP using RFC2640-aware server
+        (this currently means only wu-ftpd, which has bad security history)
+        and client (e.g., lftp).</para>
+      </listitem>
+    </itemizedlist>
 
-      <title><xref linkend="nano"/></title>
+    <para>The last four methods work because the filenames are automatically
+    converted from the sender's locale to UNICODE and stored or sent in this
+    form. They are then transparently converted from UNICODE to the
+    recipient's locale encoding.</para>
 
-      <para>The current stable version of <application>Nano</application>
-      (&nano-version;) does not support UTF-8 character encodings.  A
-      development version is available which addresses these issues.  This
-      version can be downloaded at <ulink
-      url="http://www.nano-editor.org/dist/v1.3/nano-1.3.11.tar.gz"/>.
-      Instructions for installing this version are the same as those found on
-      the <xref linkend="nano"/> page.</para>
+  </sect2>
 
-    </sect3>
+  <sect2 id="locale-wrong-multibyte-characters"
+         xreflabel="Wrong Multibyte Characters">
 
+    <title>The Program Breaks Multibyte Characters or Doesn't Count
+    Character Cells Correctly</title>
+
+    <para>Severity: High or critical</para>
+
+    <para>Many programs were written in an older era where multibyte
+    locales were not common. Such programs assume that C "char" data
+    type, which is one byte, can be used to store single characters.
+    Further, they assume that any sequence of characters is a valid
+    string and that every character occupies a single character cell.
+    Such assumptions completely break in UTF-8 locales. The visible
+    manifestation is that the program truncates strings prematurely
+    (i.e., at 80 bytes instead of 80 characters). Terminal-based
+    programs don't place the cursor correctly on the screen, don't react
+    to the "Backspace" key by erasing one character, and leave junk
+    characters around when updating the screen, usually turning the
+    screen into a complete mess.</para>
+
+    <para>Fixing this kind of problems is a tedious task from a 
+    programmer's point of view, like all other cases of retrofitting new 
+    concepts into the old flawed design. In this case, one has to redesign 
+    all data structures in order to accommodate to the fact that a complete 
+    character may span a variable number of "char"s (or switch to wchar_t 
+    and convert as needed). Also, for every call to the "strlen" and 
+    similar functions, find out whether a number of bytes, a number of 
+    characters, or the width of the string was really meant. Sometimes it 
+    is faster to write a program with the same functionality from scratch.
+    </para>
+
+    <para>Among BLFS packages, this problem applies to <xref linkend="mc"/>,
+    <xref linkend="nano"/>, <xref linkend="ed"/>, <xref linkend="xine-ui"/>
+    and all shells.</para>
+
   </sect2>
 
 </sect1>

Modified: trunk/BOOK/introduction/welcome/changelog.xml
===================================================================
--- trunk/BOOK/introduction/welcome/changelog.xml	2006-10-27 23:32:24 UTC (rev 6363)
+++ trunk/BOOK/introduction/welcome/changelog.xml	2006-10-28 07:13:18 UTC (rev 6364)
@@ -42,6 +42,19 @@
 -->
 
     <listitem>
+      <para>October 28th, 2006</para>
+      <itemizedlist>
+        <listitem>
+          <para>[dnicholson] - Changed the structure of the Locale Related
+          Issues page to describe general classes of problems. The package
+          specific workarounds have been moved to their respective pages.
+          Thanks to Alexander Patrakov for providing the rewrite, which better
+          supports these situations.</para>
+        </listitem>
+      </itemizedlist>
+    </listitem>
+
+    <listitem>
       <para>October 27th, 2006</para>
       <itemizedlist>
         <listitem>

Modified: trunk/BOOK/postlfs/editors/nano.xml
===================================================================
--- trunk/BOOK/postlfs/editors/nano.xml	2006-10-27 23:32:24 UTC (rev 6363)
+++ trunk/BOOK/postlfs/editors/nano.xml	2006-10-28 07:13:18 UTC (rev 6364)
@@ -10,6 +10,11 @@
   <!ENTITY nano-size          "891 KB">
   <!ENTITY nano-buildsize     "5.1 MB">
   <!ENTITY nano-time          "0.1 SBU">
+
+  <!-- The nano development version fixes a lot of issues w.r.t.
+       locale issues. This entity can be removed when nano-2.0 stable
+       is released and added to BLFS -->
+  <!ENTITY nano-devel-version "1.9.99pre2">
 ]>
 
 <sect1 id="nano" xreflabel="nano-&nano-version;">
@@ -34,11 +39,13 @@
     the default editor in the <application>Pine</application> package.</para>
 
     <caution>
-      <para>The <application>Nano</application> package has some issues when
-      used in a UTF-8 based locale.  A development version is available
-      which addresses these issues.  Please see the
-      <xref linkend="locale-nano"/> section of the <xref
-      linkend="locale-issues"/>.</para>
+      <para>The <application>Nano</application> package has major issues
+      when used in a UTF-8 based locale. A development version is available
+      which addresses these issues at <ulink
+      url="http://www.nano-editor.org/dist/v1.3/nano-&nano-devel-version;.tar.gz"/>.
+      This version can be installed with the same instructions shown below.
+      See the <xref linkend="locale-issues"/> page for a more general
+      discussion of these problems.</para>
     </caution>
 
     <bridgehead renderas="sect3">Package Information</bridgehead>




More information about the blfs-book mailing list