Re: Dump commands

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.

> 
> 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.

Rainer

-- 
http://lists.linuxfromscratch.org/sympa/info/lfs-support
Unsubscribe: See the above information page