Re: Run-time dynamic linking in grep

[Jim Meyering]

Reuben Thomas wrote:

> On 26 January 2011 22:03, Jim Meyering <address@hidden> wrote:
>>>> If you think one is obviously better than the other,
>>>> please explain why along with a patch to improve things.
>>>
>>> I don't have an opinion on which is better, just that they should
>>> be consistent.
>>
>> Try to justify one position or the other, then.
>
> I really don't know, I don't see really understand the grouping of
> options either way. I was just making a bug report, not trying to
> suggest how to fix it (I'll concentrate on my patches for now).
>
>> Perhaps your editor modified the patch?
>> I confirmed that it worked for me.
>> The patch I applied started with this line:
>> From 331804557bcbe8fc7a96b4bd256b4bfb901930fb Mon Sep 17 00:00:00 2001
>> ended with two blank lines after "1.7.3.5.38.gb312b", and had
>
> OK, I download the mail, I chop up to that From line, check the file
> ends as you specify, and save it. Just so I can be sure it's not Emacs
> doing something funky, I did it in Zile. The result does not have the
> SHA1 checksum you specify. (It is
> 0e8e61eaf22422f5d24d0fdc0a7601f0806e1611.) Line endings conversion in
> my mailer? I don't know. But in any case:
>
>> Your patch included a change there that converted 8 spaces to a TAB.
>
> That's right, but I'm not applying something to reverse my patch, I'm
> applying to a clean git checkout, as you specify. So why is this line
> being patched at all? The line already has 8 spaces at the start in my
> clean git checkout!

Could some tool you use have converted 8 leading spaces to a TAB
in that Makefile?  I think emacs' whitespace mode can be configured
to do that.