GNU bug report logs -
#57604
[ef]grep usage -> POSIXLY_CORRECT?
Previous Next
Full log
Message #65 received at submit <at> debbugs.gnu.org (full text, mbox):
On 9/11/22 14:45, Sam wrote:
>
>
>> On 11 Sep 2022, at 21:41, Jim Meyering <jim <at> meyering.net> wrote:
>>
>> On Thu, Sep 8, 2022 at 4:01 PM Karl Berry <karl <at> freefriends.org> wrote:
>>> Hi Jim,
>>>
>>> Some must care about portability,
>>>
>>> Certainly agreed. Even I do, sometimes :). But that does not mean
>>> everyone needs to, in every situation. As I said, I fail to understand
>>> the benefit of making the warning unconditional.
>>>
>>> So far as I can see, it's also against GNU principles, as I wrote,
>>> though evidently you don't agree.
>>>
>>> and these warnings help them do a better job.
>>>
>>> When people want extreme POSIX compliance, they should set
>>> POSIXLY_CORRECT. That's what it's there for, and that's when I think the
>>> warnings should be issued, as I said at the beginning.
>>>
>>> But since Paul rejected that, ok, a different variable that lets us turn
>>> them off (GREPWARNINGS=efgrepok or whatever) would at least provide some
>>> palliation. I don't understand why you two are opposed to this simple
>>> remediation.
>>>
>>> As Gary mentioned above, it's easy to disable them.
>>>
>>> Obviously it is trivial to edit the scripts or have a different version
>>> in PATH for my own machine(s). But those are no substitute for having a
>>> supported way to use the distributed [ef]grep without warnings.
>>>
>>> I would argue that it is even more important to retain these
>>> stray-backslash warnings, because they tend to highlight real bugs.
>>>
>>> "tend" being the key word there. But anyway, I see your point, and won't
>>> argue that one further, since the efgrep warnings are what's causing me
>>> the agony. -k
>>
>> Hi Karl,
>>
>> It would help if you could point to some malfunction.
>
> We've hit one malfunction in Gentoo: https://bugs.gentoo.org/868384.
>
> A program was using libgcrypt-config via CMake and ended up
> failing because of the warnings.
>
> (The program's usage is IMO ill-advised and it should use pkg-config,
> but that's beside the point).
>
>>
>> Consider the alternative.
>>
>> Should we release a new version of grep that provides a documented way
>> (say a configure-time option) to disable a warning about a
>> long-deprecated feature so you don't have to manually tweak the
>> four-line fgrep and egrep scripts? AFAIK, these new warnings cause no
>> malfunction.
>>
>> Wouldn't it be better to fix the roots of the problem rather than
>> piling another kludge on top to disable the annoying warnings? Think
>> about the next steps: when more and more distros cease to distribute
>> the egrep and fgrep crutches, what will people do? Eventually, we'll
>> all break the habit, at least in scripts. If you want to use it in
>> personal scripts or on the command line, create your wrapper script or
>> alias/function.
>>
>
> I honestly think at this point, it'd be better to just deem them GNU
> extensions.
After discussing this a bit in the LFS community, we tend to agree. For us in the
'from source' community, editing two short scripts is pretty trivial, but it really
shouldn't be needed.
-- Bruce
This bug report was last modified 1 year and 298 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.