public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-apps@cygwin.com
Subject: Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
Date: Fri, 28 Oct 2022 10:13:40 +0200	[thread overview]
Message-ID: <Y1uPNFz7Ezb6BNwa@calimero.vinschen.de> (raw)
In-Reply-To: <f8a59249-1090-9136-c720-6e096bc3b7a8@SystematicSw.ab.ca>

On Oct 28 00:49, Brian Inglis wrote:
> On Thu, 27 Oct 2022 18:25:45 +0200, Corinna Vinschen wrote
> > On Sep 29 12:55, Brian Inglis wrote:
> > > > 	/usr/share/doc/grep/ChangeLog
> > > > 	https://git.sv.gnu.org/gitweb/?p=grep.git;a=log;h=refs/tags/v3.8
> > > > > The change note below states that egrep and fgrep are deprecated
> > > > obsolescent commands, will be dropped in future, and from this release
> > > > until then, every use will show a stderr warning message, reminding you
> > > > how to change your commands and scripts:
> > > > > 	$ egrep ...
> > > > 	egrep: warning: egrep is obsolescent; using grep -E
> > > > 	...
> > > > 	$ fgrep ...
> > > > 	fgrep: warning: fgrep is obsolescent; using grep -F
> > > > 	...
> 
> > Please do everyone a favor and remove those warnings.  egrep and fgrep
> > are used abundantly in existing scripts and the user often has no choice
> > or no knowledge how to fix this.  If this is an upstream change, it's a
> > bad one, breaking backward compatibility.  Please fix this at least for
> > our distro.
> 
> This was released as test at the start of September, reiterated at the end
> of September on this list, then promoted to current stable and announced
> early October:
> 
> https://lists.gnu.org/archive/html/info-gnu/2022-09/msg00001.html

I was AFK from mid-September until mid-October, so I only niticed this
on my return.

> I received no feedback to these notices on the announce, cygwin and apps
> lists from users, maintainers, or developers.
> 
> This release is in Fedora Rawhide unpatched and targeted for Fedora 38.
> 
> Please note that these warnings are giving notice that egrep and fgrep have
> been deprecated as obsolescent for 15 years and will be dropped as commands
> as they have never been in POSIX, GREP_COLOR is obsolescent and treated like
> GREP_COLORS, unspecified or invalid regular expression warning diagnostics
> are now being issued on stderr as they will be treated as errors in future
> releases, "binary file matches" messages on stderr may no longer be
> suppressed, and invalid bracket expressions are now being treated as errors,
> with appropriate diagnostics and exit codes.

I'm aware of that, but upstream is obviously missing the fact that
egrep and fgrep have been part of the history for so long that they
are part of the UNIX gene pool.  As I said there are scripts out
there using egrep and fgrep.  I, for one, can easily tweak the
scripts, but not every user will be able to do so, missing the
knowledge or admin privileges.

There are also the old (and I mean old) users out there who have an
ingrained habit to use egrep and fgrep since it was *always* part
of UNIX.  The warnings are really just a PITA.


Corinna

  reply	other threads:[~2022-10-28  8:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <announce.20220904140803.17862-1-Brian.Inglis@SystematicSW.ab.ca>
2022-09-29 18:55 ` Brian Inglis
2022-10-27 16:25   ` Corinna Vinschen
2022-10-28  6:49     ` Brian Inglis
2022-10-28  8:13       ` Corinna Vinschen [this message]
2022-10-28  8:20         ` Corinna Vinschen
2022-10-28 13:36           ` Thomas Wolff
2022-11-19 20:26             ` Brian Inglis
2022-10-28 12:40       ` gs-cygwin.com
2022-10-28 14:29         ` Corinna Vinschen
2022-11-03 18:08         ` Brian Inglis
2022-11-03 18:31           ` Achim Gratz
2022-11-04  0:09             ` Richard H. Gumpertz
2022-11-04 12:47             ` Corinna Vinschen
2022-11-04 19:07             ` Brian Inglis
2022-11-04 19:27               ` Corinna Vinschen
2022-11-13 17:09                 ` Thomas Wolff
2022-11-13 22:13                   ` Brian Inglis
2022-11-14  5:21                     ` Thomas Wolff
2022-11-13 21:06 Brian Inglis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y1uPNFz7Ezb6BNwa@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).