Package: grep;
Reported by: Sam Trenholme <maradns <at> gmail.com>
Date: Thu, 13 Oct 2022 17:48:03 UTC
Severity: normal
View this message in rfc822 format
From: Shlomi Fish <shlomif <at> shlomifish.org> To: Sam Trenholme <maradns <at> gmail.com>, 58502 <at> debbugs.gnu.org Subject: 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 .
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.