Re: good patch vs. sed fixes

Am 25.11.24 um 04:46 schrieb Ken Moffat ([email protected] via
blfs-dev Mailing List):
> On Sun, Nov 24, 2024 at 01:18:23PM +0100, Rainer Fiebig wrote:
>>
>> - If you apply sed-statements (or other build-instructions) to versions
>> other than those they are intended for and the results are not as you
>> expect them, that's _your_ problem.
> 
> And that is the common case for ALL developers trying out a new
> version of a package.
> 
>>
>> - If you use a script or build-system which doesn't have safeguards for
>> such mistakes, that's again up to _you_ to solve.
>>
>> I can't see how any of those should be of general concern.  Neither are
>> they a reason to replace sed-statements with patches.  Both have their
>> specific use cases.
>>
> 
> And specifically, with a patch it is mostly reasonably simple to see
> if it applies.  Yes, I am aware of cases, particularly in the
> kernel, whare a patch has affected the wrong hunk of a file which
> has been changed since the patch was first created, but compare that
> to a sed: first you need to work out what is being changed in the
> 'intended' version by applying the sed and diffing.  Then, you ought
> to look at the new code, see if expected code is present, and if so
> does the sed fix it, and does it change any other lines.
As you know, one can be very specific with addresses in sed.  And one
can test in advance whether other lines would be affected.  With the
Seamonkey-2.53.19 sources:

> sed --silent '/ZWJ/p' intl/lwbrk/LineBreaker.cpp
    /* ZWJ = 42,                          [ZWJ]*/ CLASS_CHARACTER

So if using /ZWJ/ for the address, no other lines would be affected.
Instead of sed one could also use grep or an editor.

Now testing what the sed will do, using that from ch. Seamonkey:
> (for i in {43..47}; do
   sed '/ZWJ/s/$/,CLASS_CHARACTER/' -i.orig intl/lwbrk/LineBreaker.cpp
|| exit $?
done)

Checking the result, here with grep.  By using -i.orig one still has a
backup of the file:
> grep 'ZWJ' intl/lwbrk/LineBreaker.cpp
    /* ZWJ = 42,                          [ZWJ]*/
CLASS_CHARACTER,CLASS_CHARACTER,CLASS_CHARACTER,CLASS_CHARACTER,CLASS_CHARACTER,CLASS_CHARACTER


This procedure is pretty simple and quickly provides the desired
information.

> 
> In many cases, a sed will change other lines which do not matter.
As said, one can be very specific with addresses in sed.  If necessary,
one could take the whole line as the regexp for the address.

> On occasion when I was editing I attempted to limit a sed to only
> the desired lines (without specifying line numbers, of course) but
> often that was impractical.
Why _not_ use line numbers in such cases?  If there really are several
_identical_ lines and you don't want all of them to be changed then use
line numbers.

> 
> For those who are happy to only follow the book, and to assume that
> editors do not make mistakes or apply seds which in fact no longer do
> anything, none of that is an issue.
Which would be the vast majority of users.  And for them it's also
easier to just copy and paste a sed instead of having to download and
apply several hundreds of additional patches.  Not to mention the
educational value of learning how to use sed.

>  But for those who care about
> the development of LFS or BLFS it is something to bear in mind as
> versions of packages change.
Ken, I really don't have a clue what you want to tell me here.  But my
POV is that if a user deliberately or by lack of diligence deviates from
the books and runs into problems, it's first and foremost up to him to
solve them, if necessary with help from the support-lists.  One cannot
make a case for substituting sed-statements with patches from that.

Rainer

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