Various issues with the book

2007-02-19 Thread Chris Staub
1. Perhaps it should be made somewhat clearer that the Linux-Headers 
installation comes from the kernel tarball. More than one user has come 
into the IRC chat asking if it was the CLFS Linux-Headers package.


2. The toolchain-adjustment section says that you can edit the specs 
file by hand, but there is no specs file at all until it's generated by 
that command gcc | sed command.


3. Is m4 really needed in Chapter 5? I thought the only reason it was 
there was because of Binutils, but it doesn't need m4 now...


4. Inetutils installs programs for ipv6, including a ping6 program. 
Since the FHS says that ping must be in /bin, it would seem to make 
sense to put ping6 there too...this is what we have done in CLFS.


5. The instructions for Man-DB eliminate the reference to /usr/man in 
the manpage search path to remove potential redundant results (since 
/usr/man is a symlink to /usr/share/man). The same should be done for 
/usr/local/man.


6. Are the instructions in Texinfo for optionally installing TeX stuff 
really needed? First, there is no explanation for what TeX is. Second, 
there is no description of what exactly is installed (components 
belonging in a TeX installation - what components?). We simply removed 
that in CLFS.


7. The Udev page says that Udev does not install any rules by default. 
Actually, it does. Right make install for Udev...


[EMAIL PROTECTED]:/home/lfs/sources/udev-105# ls /etc/udev/rules.d/
60-cdrom_id.rules  75-persistent-net-generator.rules
75-cd-aliases-generator.rules

Do we want to keep those or replace them? In CLFS we simply eliminate 
the contents of /etc/udev/rules.d immediately after installing Udev.


Also, the make install-doc command for the LFS Udev rules creates the 
/usr/share/doc/udev-105 directory so the command for installing the 
documentation for writing Udev rules should be able to be shortened to 
install -m644 -v docs/writing_udev_rules/index.html 
/usr/share/doc/udev-105.


Also, I have attached a patch with a few text fixes for the book. First, 
the warning in the Bzip2 instructions about needing to run rm 
/usr/bin/bz* if you reinstall is no longer needed with the latest 
version. There are also corrections for the number of Autoconf tests 
that use Automake, and more accurate descriptions of what make install 
and make install-libs do in E2fsprogs.
Index: trunk/BOOK/chapter06/bzip2.xml
===
--- trunk/BOOK/chapter06/bzip2.xml  (revision 7926)
+++ trunk/BOOK/chapter06/bzip2.xml  (working copy)
@@ -66,10 +66,6 @@
 
 screenuserinputmake/userinput/screen
 
-paraIf reinstalling Bzip2, perform
-userinputrm -vf /usr/bin/bz*/userinput first, otherwise the following
-commandmake install/command will fail./para
-
 paraInstall the programs:/para
 
 screenuserinputmake PREFIX=/usr install/userinput/screen
Index: trunk/BOOK/chapter06/kernfs.xml
===
--- trunk/BOOK/chapter06/kernfs.xml (revision 7926)
+++ trunk/BOOK/chapter06/kernfs.xml (working copy)
@@ -59,7 +59,7 @@
   create a mirror of a directory or mount point to some other location. Use
   the following command to achieve this:/para
 
-screenuserinputmount --bind /dev $LFS/dev/userinput/screen
+screenuserinputmount -v --bind /dev $LFS/dev/userinput/screen
 
   /sect2
 
Index: trunk/BOOK/chapter06/e2fsprogs.xml
===
--- trunk/BOOK/chapter06/e2fsprogs.xml  (revision 7926)
+++ trunk/BOOK/chapter06/e2fsprogs.xml  (working copy)
@@ -42,8 +42,8 @@
 
 screenuserinputsed -i -e 's@/bin/rm@/toolsamp;@' 
lib/blkid/test_probe.in/userinput/screen
 
-paraIt is recommended that E2fsprogs be built in a subdirectory of
-the source tree: /para
+paraThe E2fsprogs documentation recommends that the package be built in
+a subdirectory of the source tree: /para
 
 screenuserinputmkdir -v build
 cd build/userinput/screen
@@ -106,11 +106,11 @@
 xref linkend=space-mounting/ for details on creating and enabling
 swap space./para
 
-paraInstall the binaries and documentation:/para
+paraInstall the binaries, documentation, and shared libraries:/para
 
 screenuserinputmake install/userinput/screen
 
-paraInstall the shared libraries:/para
+paraInstall the static libraries and headers:/para
 
 screenuserinputmake install-libs/userinput/screen
 
Index: trunk/BOOK/chapter06/autoconf.xml
===
--- trunk/BOOK/chapter06/autoconf.xml   (revision 7926)
+++ trunk/BOOK/chapter06/autoconf.xml   (working copy)
@@ -45,7 +45,7 @@
 
 paraTo test the results, issue:
 userinputmake check/userinput.
-This takes a long time, about 3 SBUs.  In addition, 2 test are skipped
+This takes a long time, about 3 SBUs.  In addition, 6 tests are skipped
 that use Automake.  For full test coverage, 

Make bootscripts more POSIX compliant

2007-02-19 Thread Dan Nicholson

After the error the other day with dash and glibc-2.3.6, I decided to
install dash[1] and give it a whirl as /bin/sh. Things went mostly
pretty well with respect to rogue bashisms throughout the system. I've
attached some patches to fix up the bootscripts while consulting the
POSIX spec on shells[2].

First patch is to eliminated echo -[en] since it's not always
supported by POSIX shells. I chose to use printf since it was a
builtin in dash. I didn't notice until later that it's not mentioned
in POSIX. And the executable printf is in /usr/bin. We can maintain
the same echo -[en] syntax by switching in /bin/echo everywhere,
too.

Second patch is just a tweak for boot_mesg. There's an excessive
pipeline using sed and grep to count the characters in the input
string. Fortunately, POSIX mandates that shells respect ${#var} to
return the length of the string. I chose to add 1 for an extra space
(the old way ended up with 2 spaces for some reason). $((...)) can be
used for arithmetic expansion according to POSIX.

Third patch is a combo because I couldn't keep the diffs separated in
the console script. First fix has to do with  syntax. This is
equivalent to file 21 according to bash(1), and that syntax is
supported by POSIX shells.

The second part has to do with trapping on ERR. Although `set -e' is
supported in POSIX, trapping is only mandated for signals. So, I just
sprinkled a bunch of conditionals through the console script to try to
achieve the same effect as the error trapping.

Let me know what you guys think.

--
Dan

[1] http://gondor.apana.org.au/~herbert/dash/
[2] http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
I don't know if printf is the right way to go since POSIX doesn't say
it needs to be a builtin from what I can see. If it's not builting,
then it's in /usr/bin, which isn't available at boot. All the shells
I've looked at have printf builtin, though.

Otherwise, we should use /bin/echo, which has the same semantics as
bash's echo.

Index: bootscripts/lfs/init.d/functions
===
--- bootscripts/lfs/init.d/functions	(revision 7926)
+++ bootscripts/lfs/init.d/functions	(working copy)
@@ -40,12 +40,12 @@
 COL=$((${COLUMNS} - 8))
 WCOL=$((${COL} - 2))
 
-## Set Cursor Position Commands, used via echo -e
+## Set Cursor Position Commands, used via printf
 SET_COL=\\033[${COL}G  # at the $COL char
 SET_WCOL=\\033[${WCOL}G# at the $WCOL char
 CURS_UP=\\033[1A\\033[0G   # Up one line, at the 0'th char
 
-## Set color commands, used via echo -e
+## Set color commands, used via printf
 # Please consult `man console_codes for more information
 # under the ECMA-48 Set Graphics Rendition section
 #
@@ -79,13 +79,13 @@
 #***
 boot_mesg()
 {
-	local ECHOPARM=
+	local ENDCHAR='\n'
 
 	while true
 	do
 		case ${1} in
 			-n)
-ECHOPARM= -n 
+ENDCHAR=
 shift 1
 ;;
 			-*)
@@ -104,7 +104,7 @@
 		-e 's,.,.,g' -e 'l 1' | grep -c \$`
 
 	# Print the message to the screen
-	echo ${ECHOPARM} -e ${2}${1}
+	printf ${2}${1}${ENDCHAR}
 	
 }
 
@@ -117,28 +117,25 @@
 boot_log()
 {
 	# Left in for backwards compatibility
-	echo -n 
+	:
 }
 
 echo_ok()
 {
-	echo -n -e ${CURS_UP}${SET_COL}${BRACKET}[${SUCCESS}  OK  ${BRACKET}]
-	echo -e ${NORMAL}
-boot_mesg_flush
+	printf ${CURS_UP}${SET_COL}${BRACKET}[${SUCCESS}  OK  ${BRACKET}]${NORMAL}\n
+	boot_mesg_flush
 }
 
 echo_failure()
 {
-	echo -n -e ${CURS_UP}${SET_COL}${BRACKET}[${FAILURE} FAIL ${BRACKET}]
-	echo -e ${NORMAL}
-boot_mesg_flush
+	printf ${CURS_UP}${SET_COL}${BRACKET}[${FAILURE} FAIL ${BRACKET}]${NORMAL}\n
+	boot_mesg_flush
 }
 
 echo_warning()
 {
-	echo -n -e ${CURS_UP}${SET_COL}${BRACKET}[${WARNING} WARN ${BRACKET}]
-	echo -e ${NORMAL}
-boot_mesg_flush
+	printf ${CURS_UP}${SET_COL}${BRACKET}[${WARNING} WARN ${BRACKET}]${NORMAL}\n
+	boot_mesg_flush
 }
 
 print_error_msg()
@@ -209,20 +206,20 @@
 			# may call it this way.
 			case ${2} in
 running)
-	echo -e -n ${CURS_UP}
-	echo -e -n \\033[${STRING_LENGTH}G   
+	printf ${CURS_UP}
+	printf \\033[${STRING_LENGTH}G   
 	boot_mesg Already running. ${WARNING}
 	echo_warning
 	;;
 not_running)
-	echo -e -n ${CURS_UP}
-	echo -e -n \\033[${STRING_LENGTH}G   
+	printf ${CURS_UP}
+	printf \\033[${STRING_LENGTH}G   
 	boot_mesg Not running. ${WARNING}
 	echo_warning
 	;;
 not_available)
-	echo -e -n ${CURS_UP}
-	echo -e -n \\033[${STRING_LENGTH}G   
+	printf ${CURS_UP}
+	printf \\033[${STRING_LENGTH}G   
 	boot_mesg Not available. ${WARNING}
 	echo_warning
 	;;
@@ -278,18 +275,18 @@
 	getpids ${1}
 
 	if [ -n ${pidlist} ];	then
-		echo -e ${INFO}${base} is running with Process\
-			ID(s) ${pidlist}.${NORMAL}
+		printf ${INFO}${base} is running with Process\
+			ID(s) ${pidlist}.${NORMAL}\n
 	else
 		if [ -n ${base} -a -e 

Re: Make bootscripts more POSIX compliant

2007-02-19 Thread Bruce Dubbs
Dan Nicholson wrote:

 First patch is to eliminated echo -[en] since it's not always
 supported by POSIX shells. I chose to use printf since it was a
 builtin in dash. I didn't notice until later that it's not mentioned
 in POSIX. And the executable printf is in /usr/bin. We can maintain
 the same echo -[en] syntax by switching in /bin/echo everywhere,
 too.

I prefer using /bin/echo.  I wonder if there would be a test to see if
echo -[en] works or not and then:

if (works) ECHO=echo
else ECHO=/bin/echo

and then use $ECHO everywhere.

  -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: Make bootscripts more POSIX compliant

2007-02-19 Thread Alexander E. Patrakov
Dan Nicholson пишет:
 After the error the other day with dash and glibc-2.3.6, I decided to
 install dash[1] and give it a whirl as /bin/sh. Things went mostly
 pretty well with respect to rogue bashisms throughout the system. I've
 attached some patches to fix up the bootscripts while consulting the
 POSIX spec on shells[2].
 
 First patch is to eliminated echo -[en] since it's not always
 supported by POSIX shells. I chose to use printf since it was a
 builtin in dash. I didn't notice until later that it's not mentioned
 in POSIX. And the executable printf is in /usr/bin. We can maintain
 the same echo -[en] syntax by switching in /bin/echo everywhere,
 too.

Could you please install posh from 
http://ftp.debian.org/debian/pool/main/p/posh/posh_0.5.4.tar.gz and test 
whether it reveals any additional breakage?

 Second patch is just a tweak for boot_mesg. There's an excessive
 pipeline using sed and grep to count the characters in the input
 string. Fortunately, POSIX mandates that shells respect ${#var} to
 return the length of the string. I chose to add 1 for an extra space
 (the old way ended up with 2 spaces for some reason). $((...)) can be
 used for arithmetic expansion according to POSIX.

The reason for this sed was that I planned to include translation of boot 
messages and cope with broken shells like ash that don't count characters in 
UTF-8 locales properly (i.e., the reality is that ${#var} is a bashism, even 
though it is mandated by POSIX).

However, since two earlier attempts produced working boot scripts that 
caused absolutely no interest in the LFS community, I revoke the plan, and 
propose to use ${#var}, because it works correctly for English messages (and 
our bootscripts will not produce anything else).

   ## Figure out the length of what is to be printed to be used
 -## for warning messges. 
 - STRING_LENGTH=`echo ${1} | sed \
 - -e 's,.,.,g' -e 'l 1' | grep -c \$`
 + ## for warning messges. 
 + STRING_LENGTH=$((${#1} + 1))

+1

-- 
Alexander E. Patrakov
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: Make bootscripts more POSIX compliant

2007-02-19 Thread TheOldFellow
Dan Nicholson wrote:
 After the error the other day with dash and glibc-2.3.6, snip

I prefer to install bash and start all the bootscripts #!/bin/bash to
make it clear that anyone who wants to use another shell is on their
own.  :-)

R.

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: Make bootscripts more POSIX compliant

2007-02-19 Thread Dan Nicholson
On 2/19/07, Bruce Dubbs [EMAIL PROTECTED] wrote:
 Dan Nicholson wrote:

  First patch is to eliminated echo -[en] since it's not always
  supported by POSIX shells. I chose to use printf since it was a
  builtin in dash. I didn't notice until later that it's not mentioned
  in POSIX. And the executable printf is in /usr/bin. We can maintain
  the same echo -[en] syntax by switching in /bin/echo everywhere,
  too.

 I prefer using /bin/echo.  I wonder if there would be a test to see if
 echo -[en] works or not and then:

 if (works) ECHO=echo
 else ECHO=/bin/echo

 and then use $ECHO everywhere.

Excellent idea. What's below seems to work. A more complete test can
be found near the beginning of any autoconf generated configure
script, but it doesn't really fit our usage pattern.

case `echo -en test` in
-en*)
ECHO=/bin/echo
;;
*)
ECHO=echo
;;
esac

--
Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: Make bootscripts more POSIX compliant

2007-02-19 Thread Dan Nicholson
On 2/19/07, Alexander E. Patrakov [EMAIL PROTECTED] wrote:

 Could you please install posh from
 http://ftp.debian.org/debian/pool/main/p/posh/posh_0.5.4.tar.gz and test
 whether it reveals any additional breakage?

I'll take a look at it. Any background on posh?

  Second patch is just a tweak for boot_mesg. There's an excessive
  pipeline using sed and grep to count the characters in the input
  string. Fortunately, POSIX mandates that shells respect ${#var} to
  return the length of the string. I chose to add 1 for an extra space
  (the old way ended up with 2 spaces for some reason). $((...)) can be
  used for arithmetic expansion according to POSIX.

 The reason for this sed was that I planned to include translation of boot
 messages and cope with broken shells like ash that don't count characters in
 UTF-8 locales properly (i.e., the reality is that ${#var} is a bashism, even
 though it is mandated by POSIX).

I see.

 However, since two earlier attempts produced working boot scripts that
 caused absolutely no interest in the LFS community, I revoke the plan, and
 propose to use ${#var}, because it works correctly for English messages (and
 our bootscripts will not produce anything else).

How would an implementation of translated messages work in general? gettext?

--
Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page


Re: Make bootscripts more POSIX compliant

2007-02-19 Thread Dan Nicholson
On 2/19/07, TheOldFellow [EMAIL PROTECTED] wrote:
 Dan Nicholson wrote:
  After the error the other day with dash and glibc-2.3.6, snip

 I prefer to install bash and start all the bootscripts #!/bin/bash to
 make it clear that anyone who wants to use another shell is on their
 own.  :-)

Very true. But a big motivation of using dash is that it's much more
lightweight than bash, presumably providing some speedup for simple
scripts where lots of features aren't needed. I do love a bash script,
though.

--
Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page