Re: good patch vs. sed fixes

Am 25.11.24 um 23:34 schrieb Ken Moffat ([email protected] via
blfs-dev Mailing List):
> On Mon, Nov 25, 2024 at 02:10:06PM +0100, Rainer Fiebig wrote:
>> Am 25.11.24 um 04:46 schrieb Ken Moffat ([email protected] via
>> blfs-dev Mailing List):
> 
>> 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.
>>
> 
> Noted.
> 
>>>
>>> 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.
>>
> 
> Try doing that in C++ code which needs to be be updated for a newer
> C++ version but has several sets of parentheses and several sets of
> squate brackets.  I assume it can probably be done, but with a
> horrendously long regex.
Not necessarily.  It's relatively easy and clear when using a variable.
 In this example only a few brackets needed to be escaped:

line="    if (IS_CJK_CHAR(aText\[begin\]) ||
NS_NeedsPlatformNativeHandling(aText\[begin\])) {"

Finding/printing the line with sed:
sed --silent "/$line/p" intl/lwbrk/LineBreaker.cpp
    if (IS_CJK_CHAR(aText[begin]) ||
NS_NeedsPlatformNativeHandling(aText[begin])) {

With grep:
grep -n "$line" intl/lwbrk/LineBreaker.cpp
884:    if (IS_CJK_CHAR(aText[begin]) ||
NS_NeedsPlatformNativeHandling(aText[begin])) {


But I think that cases where one really would have to use the whole line
for the address are the exception and not the rule.

> 
>>> 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.
>>
> 
> Line numbers worh in the current version.  As soon as something
> changes in the file, line nubers still apply (unless now after EOF)
> but will do nothing useful
In new versions things need to be checked, that's right.  But for _me_
that would be no compelling reason for "patches-only" LFS/BLFS.

> 
>>>
>>> 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
> 
> This list was originally for the development of the book. Uwe's
> posts were related to changes for a newer version.  For development,
> being prepared to deviate from the current book is necessary.
Sure.  And I'm aware that this is blfs-dev.  But I think that the
changes indicated by the OP would not make the books any better nor
would they be helpful for LFS/BLFS users.

> 
> I agree that learning sed can be a useful skill.
It would be a disservice to users if sed vanished from the books.

Rainer

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