[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#57604: [ef]grep usage -> POSIXLY_CORRECT?

From: Jim Meyering
Subject: bug#57604: [ef]grep usage -> POSIXLY_CORRECT?
Date: Fri, 16 Sep 2022 01:30:16 -0700

On Thu, Sep 15, 2022 at 9:28 PM Guillem Jover <guillem@debian.org> wrote:
> On Fri, 2022-09-09 at 11:41:49 -0500, Paul Eggert wrote:
> > On 9/9/22 07:16, Guillem Jover wrote:
> > > There are now packages that fail to work such as
> > > apt-file (https://bugs.debian.org/1019329),
> >
> > From what I can see, that bug report doesn't say that apt-file fails to
> > work, only that apt-file issues a warning and then goes on to work.
> Ah, you are right, that might have coincided with a query I did that
> returned nothing then, sorry about that!
> > > Transitioning away from fgrep/egrep seems like it would be painful as
> > > that involves lots of upstream projects:
> >
> > I glanced at those, and didn't see any projects that will stop working, only
> > projects that will see annoying warnings. Admittedly I didn't look at all
> > the examples, but in the first page of
> > <https://codesearch.debian.net/search?q=fgrep&literal=1> (your first
> > citation) all the code examples should continue to work.
> >
> > Could you give examples of programs that actually stop working? That would
> > help us consider remedies.
> It's true that most of those instances are probably not going to fail.
> But what is definitely being affected are autopkgtests from Debian
> packages for example. By default those consider any output to stderr
> a signal to mark the test as failing. So the new grep failures are
> causing unrelated tests to fail now.
> Some are going to be hard to fix locally, or quickly everywhere, for
> example the one in libtool, as until it is fixed, relibtoolizing will
> have not effect, and afterwards that will get fixed only as long as
> the packaging always forcibly relibtoolizes (or autoreconfigures).
> <https://bugs.debian.org/1019725>
> As I've mentioned earlier, personally, I definitely want to be able to
> see those kinds of warnings so that I can fix or change stuff I
> maintain, or report bugs with patches. But unfortunately it seems this
> is causing enough disruption that all the new warnings might end up
> being disabled in Debian. I think it's been discussed earlier that
> environment variables are not desired? But I think it would still be nice
> to be able to control those warnings globally/externally, so that even
> if say a project like Debian ends up disabling them, people can still
> enable them to be able to diagnose and track those down.

Thanks for the feedback.

We may make a new release with two additions:
- an envvar to control [ef]grep warnings, enabled by default
- a configure-time option to make it disabled by default

This would be an envvar for which we do not commit to any level of
support in future releases.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]