| Newsgroups |
gmane.linux.lfs.support |
| Message-ID |
<[email protected]> |
On Sat, 2026-08-15 at 11:22 +0200, Rainer Fiebig wrote:
> Am 13.08.26 um 18:47 schrieb Bruce Dubbs ([email protected] via
> lfs-support Mailing List):
> > On 8/13/26 5:58 AM, Rainer Fiebig ([email protected] via lfs-support
> > Mailing List) wrote:
> > > Am 13.08.26 um 03:41 schrieb Bruce Dubbs
> > > ([email protected] via
> > > lfs-support Mailing List):
> > > > On 8/12/26 2:51 PM, Pocket ([email protected] via lfs-
> > > > support
> > > > Mailing List) wrote:
> > > > >
> > >
> > > / snip /
> > >
> > > > > case $(uname -m) in
> > > > > x86_64) chown -v lfs
> > > > > $LFS/lib64 ;;
> > > > > esac
> > > / snip /
> > >
> > > Successful execution of
> > >
> > > chown -v lfs $LFS/lib64
> > >
> > > does not depend on whether the machine is x86_64 or not but
> > > whether
> > > directory "$LFS/lib64" exists or not. That directory was already
> > > created (or not) in ch. 4.2:
> > >
> > > case $(uname -m) in
> > > x86_64) mkdir -pv $LFS/lib64 ;;
> > > esac
> > >
> > > So the test in ch. 4.3 should _not_ be
> > >
> > > case $(uname -m) in ...
> > >
> > > but rather
> > >
> > > if [[ -d $LFS/lib64 ]]; then
> > > chown -v lfs $LFS/lib64
> > > fi
> > >
> > > Apart from that I'm not sure whether using multi-way decision-
> > > test
> > > "case" for a one-way test is really a good choice for an
> > > educational
> > > project. At least not without a default case.
> > >
> > > BTW: I think that the dot after the last digit in chapter-
> > > headings like
> > > 4.3. Adding the LFS User
> > > is wrong or at least quite unusual.
> >
> > I agree with you Rainer on both issues. However they are fairly
> > minor
> > issues and I do not want to address them right now due to the
> > workload
> > for release. If we get ahead of the testing we might be able to
> > adjust
> > those but they will be low priority.
>
> Right, there is no need for speed in these matters. After the
> release
> would be appropriate. But "low priority"? I'm not so sure about
> that.
>
> >
> > For the case vs if issue, there are several places where that's
> > done.
> > They have been in place for many years and are known to work.
>
> Well, "We've always done it this way" is not a really convincing
> argument. Or is it? ;)
>
> In this particular "case", testing again for x86_64 instead of
> $LFS/lib64 in ch. 4.3 goes against the flow of instructions in the
> book
> and doesn't make much sense.
I don't agree. The logic is that the next instruction has to be run
only if the machine is 64 bit. How the test is done, using uname or the
presence of $LFS/lib64 is a matter of taste and both can make sense.
Now, for the use of "case" for this test, it comes from "ancient
history". Around 2014, the instructions used~:
case $(uname -m) in
i?86) blah ;
esac
And programming this using "if" instructions is much more difficult (in
bash, it would be something like (not tested):
if [[ $(uname -m) =~ i.86 ]]; then
blah
fi
but it is a "bashism". "case" is more portable.
I guess this has been ported to x86_64 without change (except the blah
part, and the absence of question mark). Changing to using "if" is
therefore ok.
>
> >
> > For the dot after the section numbering the issue is purely
> > cosmetic and
> > would require a change to the appropriate stylesheet.
>
> Cosmetics matter - just take the boom in plastic surgery as an
> indication. But seriously: the heading-numbering is plain wrong and
> ugly - that it has gone unnoticed for so long doesn't make it any
> better. To me it seems somewhat unworthy of a standard work in the
> Linux world. And I think that removing a dot from a stylesheet vs.
> correct headings provides an uncommonly favourable cost/benefit
> ratio.
The only problem is to dig into stylesheets which are modifications of
docbook-xsl stylesheets written in 2006 or so...
Pierre
--
http://lists.linuxfromscratch.org/sympa/info/lfs-support
Unsubscribe: See the above information page