GNU bug report logs - #58502
We should not deprecate egrep and fgrep

Previous Next

To reply to this bug, email your comments to 58502 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sam Trenholme <maradns <at> gmail.com>
To: bug-grep <at> gnu.org
Cc: Paul Eggert <eggert <at> cs.ucla.edu>
Subject: We should not deprecate egrep and fgrep
Date: Thu, 13 Oct 2022 10:46:32 -0700

After spending nearly an hour updating all of the scripts in the test
framework for one of my open source projects to no longer use egrep,
I’m going to say it:

We should not deprecate egrep and fgrep

egrep and fgrep have been around since the 1970s, were in wide use
well over 25 years ago on the SunOS machines we used at the time, and
are widely supported, e.g. Busybox includes an fgrep and egrep.

Even the Posix spec acknowledges that that should remain supported for
the foreseeable future:

“The old egrep and fgrep commands are likely to be supported for many
years to come as implementation extensions, allowing historical
applications to operate unmodified.”

See https://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html

Here is the amount of headache I went through to replace egrep with grep -E:

https://github.com/samboy/MaraDNS/commit/afc9d1800f3a641bdf1bf14d39802443a34c2b70

There are countless other shell scripts out there on countless
machines which still use these commands. We should not lightly break
widely deployed software, especially software which only needs two
one-line shell scripts.

-- Sam

Message #8 received at 58502 <at> debbugs.gnu.org (full text, mbox):

From: Sam James <sam <at> gentoo.org>
To: Sam Trenholme <maradns <at> gmail.com>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 58502 <at> debbugs.gnu.org
Subject: Re: bug#58502: We should not deprecate egrep and fgrep
Date: Thu, 13 Oct 2022 18:52:51 +0100

[Message part 1 (text/plain, inline)]

> On 13 Oct 2022, at 18:46, Sam Trenholme <maradns <at> gmail.com> wrote:
> 
> After spending nearly an hour updating all of the scripts in the test
> framework for one of my open source projects to no longer use egrep,
> I’m going to say it:
> 
> We should not deprecate egrep and fgrep
> 
> egrep and fgrep have been around since the 1970s, were in wide use
> well over 25 years ago on the SunOS machines we used at the time, and
> are widely supported, e.g. Busybox includes an fgrep and egrep.
> 
> Even the Posix spec acknowledges that that should remain supported for
> the foreseeable future:
> 
> “The old egrep and fgrep commands are likely to be supported for many
> years to come as implementation extensions, allowing historical
> applications to operate unmodified.”
> 
> See https://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html
> 
> Here is the amount of headache I went through to replace egrep with grep -E:
> 
> https://github.com/samboy/MaraDNS/commit/afc9d1800f3a641bdf1bf14d39802443a34c2b70
> 
> There are countless other shell scripts out there on countless
> machines which still use these commands. We should not lightly break
> widely deployed software, especially software which only needs two
> one-line shell scripts.

Yep, I really do agree -- and Iv'e already provided examples of things
which did break in the wild. Just make it a GNU extension and call it a day.

While I sympathise with the maintainers' perspective, it's pretty
clear that in reality, nobody actually realised it was "obsolescent"
and in fact actively using it in new scripts.

Really, speaking from my perspective, distribution maintainers have
got enough going on with various fires (Clang 16, OpenSSL 3,
time64 migration, ...) that handling various trivial-but-numerous
grep bugs on top is not very helpful :(

Best,
sam

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at 58502 <at> debbugs.gnu.org (full text, mbox):

From: Shlomi Fish <shlomif <at> shlomifish.org>
To: Sam James <sam <at> gentoo.org>
Cc: Sam Trenholme <maradns <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>,
 58502 <at> debbugs.gnu.org
Subject: Re: bug#58502: We should not deprecate egrep and fgrep
Date: Fri, 14 Oct 2022 01:00:33 +0300

hi all,

On Thu, 13 Oct 2022 18:52:51 +0100
Sam James <sam <at> gentoo.org> wrote:

> > On 13 Oct 2022, at 18:46, Sam Trenholme <maradns <at> gmail.com> wrote:
> > 
> > After spending nearly an hour updating all of the scripts in the test
> > framework for one of my open source projects to no longer use egrep,
> > I’m going to say it:
> > 
> > We should not deprecate egrep and fgrep
> > 
> > egrep and fgrep have been around since the 1970s, were in wide use
> > well over 25 years ago on the SunOS machines we used at the time, and
> > are widely supported, e.g. Busybox includes an fgrep and egrep.
> > 
> > Even the Posix spec acknowledges that that should remain supported for
> > the foreseeable future:
> > 
> > “The old egrep and fgrep commands are likely to be supported for many
> > years to come as implementation extensions, allowing historical
> > applications to operate unmodified.”
> > 
> > See https://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html
> > 
> > Here is the amount of headache I went through to replace egrep with grep -E:
> > 
> > https://github.com/samboy/MaraDNS/commit/afc9d1800f3a641bdf1bf14d39802443a34c2b70
> > 
> > There are countless other shell scripts out there on countless
> > machines which still use these commands. We should not lightly break
> > widely deployed software, especially software which only needs two
> > one-line shell scripts.  
> 
> Yep, I really do agree -- and Iv'e already provided examples of things
> which did break in the wild. Just make it a GNU extension and call it a day.
> 
> While I sympathise with the maintainers' perspective, it's pretty
> clear that in reality, nobody actually realised it was "obsolescent"
> and in fact actively using it in new scripts.
> 
> Really, speaking from my perspective, distribution maintainers have
> got enough going on with various fires (Clang 16, OpenSSL 3,
> time64 migration, ...) that handling various trivial-but-numerous
> grep bugs on top is not very helpful :(
> 

+1. hope i'm not "alayhum"ing / "lynch"ing here, but I agree that breaking
backcompat for vanity is bad.

> Best,
> sam



-- 

Shlomi Fish       https://www.shlomifish.org/
Perl Elems to Avoid - https://perl-begin.org/tutorials/bad-elements/

Chuck Norris knows who John Galt is.
    — https://www.shlomifish.org/humour/bits/facts/Chuck-Norris/

Please reply to list if it's a mailing list post - https://shlom.in/reply .

Message #14 received at 58502 <at> debbugs.gnu.org (full text, mbox):

From: Sam Trenholme <maradns <at> gmail.com>
To: Shlomi Fish <shlomif <at> shlomifish.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, Sam James <sam <at> gentoo.org>,
 58502 <at> debbugs.gnu.org
Subject: Re: bug#58502: We should not deprecate egrep and fgrep
Date: Thu, 13 Oct 2022 16:29:21 -0700

>vanity

Presumably, "vanity" here is the older definition which more
accurately renders as "frivolous" in modern English, as in not
important or meaningless.

I think the point the GNU grep maintainers are making is that egrep
and fgrep, much to my surprise, aren't actually part of POSIX.
Personally, I think that's a bug in POSIX, and hopefully a future
POSIX spec will mandate some implementation of egrep and fgrep, even
if it's a `exec grep -E "$@"` implementation. Even with Busybox, which
does the equivalent transformation in C code, it's about 10 lines of
code, e.g. "if ((ENABLE_EGREP && applet_name[0] == 'e')" in the same
"if" which checks for the "-E" flag.

I would, as suggested earlier, just make it a non-POSIX GNU extension,
even though POSIX itself points out that egrep and fgrep are around to
not break old scripts. grep -P, with PCRE support, isn't POSIX either,
so there's precedent to extend GNU grep beyond what POSIX mandates.

-- Sam

On Thu, Oct 13, 2022 at 3:00 PM Shlomi Fish <shlomif <at> shlomifish.org> wrote:
>
> hi all,
>
> On Thu, 13 Oct 2022 18:52:51 +0100
> Sam James <sam <at> gentoo.org> wrote:
>
> > > On 13 Oct 2022, at 18:46, Sam Trenholme <maradns <at> gmail.com> wrote:
> > >
> > > After spending nearly an hour updating all of the scripts in the test
> > > framework for one of my open source projects to no longer use egrep,
> > > I’m going to say it:
> > >
> > > We should not deprecate egrep and fgrep
> > >
> > > egrep and fgrep have been around since the 1970s, were in wide use
> > > well over 25 years ago on the SunOS machines we used at the time, and
> > > are widely supported, e.g. Busybox includes an fgrep and egrep.
> > >
> > > Even the Posix spec acknowledges that that should remain supported for
> > > the foreseeable future:
> > >
> > > “The old egrep and fgrep commands are likely to be supported for many
> > > years to come as implementation extensions, allowing historical
> > > applications to operate unmodified.”
> > >
> > > See https://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html
> > >
> > > Here is the amount of headache I went through to replace egrep with grep -E:
> > >
> > > https://github.com/samboy/MaraDNS/commit/afc9d1800f3a641bdf1bf14d39802443a34c2b70
> > >
> > > There are countless other shell scripts out there on countless
> > > machines which still use these commands. We should not lightly break
> > > widely deployed software, especially software which only needs two
> > > one-line shell scripts.
> >
> > Yep, I really do agree -- and Iv'e already provided examples of things
> > which did break in the wild. Just make it a GNU extension and call it a day.
> >
> > While I sympathise with the maintainers' perspective, it's pretty
> > clear that in reality, nobody actually realised it was "obsolescent"
> > and in fact actively using it in new scripts.
> >
> > Really, speaking from my perspective, distribution maintainers have
> > got enough going on with various fires (Clang 16, OpenSSL 3,
> > time64 migration, ...) that handling various trivial-but-numerous
> > grep bugs on top is not very helpful :(
> >
>
> +1. hope i'm not "alayhum"ing / "lynch"ing here, but I agree that breaking
> backcompat for vanity is bad.
>
> > Best,
> > sam
>
>
>
> --
>
> Shlomi Fish       https://www.shlomifish.org/
> Perl Elems to Avoid - https://perl-begin.org/tutorials/bad-elements/
>
> Chuck Norris knows who John Galt is.
>     — https://www.shlomifish.org/humour/bits/facts/Chuck-Norris/
>
> Please reply to list if it's a mailing list post - https://shlom.in/reply .

Message #17 received at 58502 <at> debbugs.gnu.org (full text, mbox):

From: Shlomi Fish <shlomif <at> shlomifish.org>
To: Sam Trenholme <maradns <at> gmail.com>, 58502 <at> debbugs.gnu.org
Subject: Re: bug#58502: We should not deprecate egrep and fgrep
Date: Fri, 14 Oct 2022 12:20:15 +0300

hi,

[resending in public this time]

On Thu, 13 Oct 2022 16:29:21 -0700
Sam Trenholme <maradns <at> gmail.com> wrote:

> >vanity  
> 
> Presumably, "vanity" here is the older definition which more
> accurately renders as "frivolous" in modern English, as in not
> important or meaningless.
> 

yes, that's what I meant. also see 'davka' in hebrew:
https://www.joelonsoftware.com/2004/12/06/news-45/

> I think the point the GNU grep maintainers are making is that egrep
> and fgrep, much to my surprise, aren't actually part of POSIX.
> Personally, I think that's a bug in POSIX, and hopefully a future
> POSIX spec will mandate some implementation of egrep and fgrep, even
> if it's a `exec grep -E "$@"` implementation. Even with Busybox, which

I, OTOH, grew to appreciate POSIX's minimalism:
https://twitter.com/shlomif/status/1542047869989011457 .

> does the equivalent transformation in C code, it's about 10 lines of
> code, e.g. "if ((ENABLE_EGREP && applet_name[0] == 'e')" in the same
> "if" which checks for the "-E" flag.
> 
> I would, as suggested earlier, just make it a non-POSIX GNU extension,
> even though POSIX itself points out that egrep and fgrep are around to
> not break old scripts. grep -P, with PCRE support, isn't POSIX either,
> so there's precedent to extend GNU grep beyond what POSIX mandates.
> 
> -- Sam
> 
> On Thu, Oct 13, 2022 at 3:00 PM Shlomi Fish <shlomif <at> shlomifish.org> wrote:
> >
> > hi all,
> >
> > On Thu, 13 Oct 2022 18:52:51 +0100
> > Sam James <sam <at> gentoo.org> wrote:
> >  
> > > > On 13 Oct 2022, at 18:46, Sam Trenholme <maradns <at> gmail.com> wrote:
> > > >
> > > > After spending nearly an hour updating all of the scripts in the test
> > > > framework for one of my open source projects to no longer use egrep,
> > > > I’m going to say it:
> > > >
> > > > We should not deprecate egrep and fgrep
> > > >
> > > > egrep and fgrep have been around since the 1970s, were in wide use
> > > > well over 25 years ago on the SunOS machines we used at the time, and
> > > > are widely supported, e.g. Busybox includes an fgrep and egrep.
> > > >
> > > > Even the Posix spec acknowledges that that should remain supported for
> > > > the foreseeable future:
> > > >
> > > > “The old egrep and fgrep commands are likely to be supported for many
> > > > years to come as implementation extensions, allowing historical
> > > > applications to operate unmodified.”
> > > >
> > > > See https://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html
> > > >
> > > > Here is the amount of headache I went through to replace egrep with
> > > > grep -E:
> > > >
> > > > https://github.com/samboy/MaraDNS/commit/afc9d1800f3a641bdf1bf14d39802443a34c2b70
> > > >
> > > > There are countless other shell scripts out there on countless
> > > > machines which still use these commands. We should not lightly break
> > > > widely deployed software, especially software which only needs two
> > > > one-line shell scripts.  
> > >
> > > Yep, I really do agree -- and Iv'e already provided examples of things
> > > which did break in the wild. Just make it a GNU extension and call it a
> > > day.
> > >
> > > While I sympathise with the maintainers' perspective, it's pretty
> > > clear that in reality, nobody actually realised it was "obsolescent"
> > > and in fact actively using it in new scripts.
> > >
> > > Really, speaking from my perspective, distribution maintainers have
> > > got enough going on with various fires (Clang 16, OpenSSL 3,
> > > time64 migration, ...) that handling various trivial-but-numerous
> > > grep bugs on top is not very helpful :(
> > >  
> >
> > +1. hope i'm not "alayhum"ing / "lynch"ing here, but I agree that breaking
> > backcompat for vanity is bad.
> >  
> > > Best,
> > > sam  
> >
> >
> >
> > --
> >
> > Shlomi Fish       https://www.shlomifish.org/
> > Perl Elems to Avoid - https://perl-begin.org/tutorials/bad-elements/
> >
> > Chuck Norris knows who John Galt is.
> >     — https://www.shlomifish.org/humour/bits/facts/Chuck-Norris/
> >
> > Please reply to list if it's a mailing list post - https://shlom.in/reply .
> >  



-- 

Shlomi Fish       https://www.shlomifish.org/
My Photos - https://www.flickr.com/photos/shlomif/

I have a brilliant idea: a distributed, NoSQL, Webscale™ /dev/null alternative.
I’m going to patent it. (Inspired by arubin on ##programming.)

Please reply to list if it's a mailing list post - https://shlom.in/reply .

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.