Randy McMurchy wrote:
[EMAIL PROTECTED] wrote these words on 12/26/05 13:00 CST:
+<para>Since the release of Ncurses-&ncurses-version;, some bugs have been fixed
+and features added. The most important news are .......
Was the remainder of this sentence intentionally left out? If so,
what is the point? Additionally, an ellipsis (if this is what is
intended) is typically only 3 dots.
This is supposed to be inside a comment, to be uncommented and completed
if a dated snapshot is used.
+<note><para>The instructions above don't create non-wide-character Ncurses
+libraries since nothing in LFS and BLFS would link against them at runtime.
What does LFS and BLFS have to do with it? Is LFS built with the
expectation that only LFS and BLFS packages will ever be built
on top of LFS? And that only they will be supported?
"in LFS and BLFS would link" should be changed to "ever links".
If the sentence cannot be changed to this because it would then
be untrue, then the libraries need to be built.
Build e.g. Screen-4.0.2 on top of the UTF-8 LFS to see what I mean, or
read the Readline page. It wants -lcurses, and gets linked to
libncursesw. If you build everything from source (even beyond BLFS),
everything that wants some form of curses gets linked to libncursesw.
The only way to obtain a program that shows "libncurses.so.5" in the ldd
output is to install a binary package.
+If you must have such libraries because of some binary-only application,
+build them with the following commands:</para>
+<screen role="nodump"><userinput>make distclean &&
+./configure --prefix=/usr --with-shared --without-normal \
+ --without-debug --without-cxx-binding &&
Noted that the previous configure line didn't include
--without-cxx-binding and the description is commented out. Should
it be included here?
--without-cxx-binding is included here because this binding builds only
a static library, which cannot be needed for satisfying dependencies of
a binary package.
+<filename class="libraryfile">libncurses</filename>
+(really, <filename class="libraryfile">libncursesw</filename>)
+library.
Why can't we just say what it is? Why must there be one library
listed, with in parenthesis listing what is really linked to?
This is intended to be a demonstration how applications that at
compilation time want -lncurses get actually linked to libncursesw. If
you can write a better explanation how the /usr/lib/libncurses.so linker
script works, please do it.
+codes. Such replacement caused damage to messages in UTF-8 encoding.</para>
Should it be "Such replacement causes damage"? (s/caused/causes/)
Maybe: "Unpatched sysklogd would, therefore, damage messages in the
UTF-8 encoding". Or anything equivalent.
+<para>The <command>info</command> program makes assumptions such as "a string
+occupies the same number of character cells on the screen and bytes in memory"
+and "one can break the string anywhere" that are incorrect in UTF-8 locales.
Is there somewhere within the info source code or documentation
that actually quotes the above stuff? If not, the sentence needs
to be revised, or the quotes removed, or something.
Remove quotes.
+While the patch below is not the proper solution, it at least hides the problem
+by falling back to English messages when a multibyte locale is in use:</para>
This brings about the obvious questions of:
What is the proper solution and why is it not being implemented?
Proper solution: rewrite the code so that it doesn't make the mentioned
assumptions. Too hard for me.
+<screen><userinput>install -m755 ../console
/etc/rc.d/init.d</userinput></screen>
Shouldn't this be set to 754 perms?
OK
+ HOWTO's can also help with this, see <ulink
HOWTO's should be HOWTOs. It is not used in a possessive context not
is it a contraction.
+ <para>This variable specifies the arguments for the
+ <command>loadkeys</command> program, typically, the name of keymap
+ to load, e.g. "es".
Should e.g. have a comma after it?
The <command>console</command> bootscript will
+ convert an available keymap to UTF-8 on the fly if this variable is
Again, "on the fly" could be construed improperly by non-native
English readers. Couldn't this be used instead?:
The console bootscript will automatically convert an available keymap
to UTF-8 if this variable is
+ <para>Set this to "0" if you are going to apply that kernel patch in
+ Chapter 8.
s/that/the/
+ <para>Here is a Unicode-enabled example
Perhaps (because in writing "here" used in this manner is usually
considered ambiguous) s/Here/The following/
+ Maybe another sed has to be added to groff instructions that will remove
+ both issues.
If this were ever uncommented, sed needs <command> tags, "the" should be
inserted in front of groff and groff capitalized.
+ <para>The following example illustrates keymap autoconversion from
+ ISO-8859-15 to UTF-8 and enabling dead keys in Unicode mode:</para>
This is the second instance of "dead keys". I don't even know what
a "dead key" is. Perhaps it could be explained or some other term
used instead?
+ <para>For Chinese, Japanese, Korean and some other languages, the Linux
+ console cannot be configured to display the needed characters. Users
+ who need such languages should install the X Window System, fonts that
+ cover the necessary character ranges, and the proper input Method (e.g.
+ SCIM, it supports a wide variety of languages).</para>
Two things. One, perhaps a comma after e.g. and two, does Method
need to be capitalized? Is it being used as a proper noun here?
+ <para>The <filename>/etc/sysconfig/console</filename> file only controls
+ Linux text console localization. It has nothing to do with setting the
proper
+ keyboard layout and terminal fonts in X Window System.</para>
Should perhaps "the" or "an" be inserted before X Window System?
- <para>Locales can have a number of synonyms, e.g. <quote>ISO-8859-1</quote>
+ <para>Charmaps can have a number of aliases, e.g. <quote>ISO-8859-1</quote>
Should there be a comma after e.g.?
+ Some applications cannot handle the various synonyms correctly (e.g.
Ditto.
My typical mistake, sorry.
+ <para>The <quote>C</quote> (default) and <quote>en_US</quote> (the
recommended
+ one for United States English users) locales are different.
Instead of "the recommended one" could it be just "recommended"?
OK
results in non-RFC-conforming
+ messages being set
Should "set" be "sent" here?
Sorry, typo.
+ impossible (without damaging non-ASCII characters) to connect using ssh from
ssh should be encapsulated in <command> tags
The ssh example should be removed because I am actually wrong here: BLFS
can help you with Screen-4.0.2 (but it has to be documented on the ssh
page).
In order to connect from your UTF-8 system to the host that uses
ISO-8859-1, do the following:
screen
ctrl+A
:encoding ISO-8859-1
ssh the.remote.host
+ <para>It is also possible to specify default codepage and iocharset values
for
+ some filesystems during kernel configuration, the relevant parameters
+ are named
Shouldn't this be two independent sentences separated by a period
instead of a comma?
OK
+ <para>By default, Linux kernel generates wrong sequences of bytes when
s/Linux kernel/the Linux kernel/
OK
+ dead keys are used in UTF-8 keyboard mode. Also, one cannot copy and paste
Dead keys?
http://en.wikipedia.org/wiki/Dead_key
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-book
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
