public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
       [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
  0 siblings, 1 reply; 19+ messages in thread
From: Brian Inglis @ 2022-09-29 18:55 UTC (permalink / raw)
  To: Cygwin Applications; +Cc: Brian Inglis

Hi folks, [Please Reply All as ISP blocking Cygwin lists]

I would like to untest and promote this test package to current stable 
this coming weekend, which may result in command and escape warnings 
appearing, unless anyone would like more time to release package 
updates, to avoid causing these command and escape warnings, which may 
result in support emails.

See release notes at bottom for more details, install the test package 
to see the warnings, and see the suggestions below for checks.

Since installing this test package, I have noticed command and escape 
warnings on stderr from various other packages during operations and 
cygport builds, but nothing so far has produced errors and failed.

Please email this list, and CC me as requested, if you would like me to 
further postpone release of this package upgrade.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada


On 2022-09-04 14:08, Cygwin grep Co-Maintainer wrote:
> The following package has been uploaded for testing to the Cygwin distribution:
> 
> * grep	3.8
> 
> GNU grep searches one or more input files for lines containing a match
> to a specified pattern. By default, grep outputs the matching lines. The
> GNU implementation includes several useful extensions over POSIX.
> 
> For more information see the project home pages:
> 
> 	https://www.gnu.org/software/grep/
> 	https://sv.gnu.org/projects/grep/
> 
> For changes since the previous Cygwin release please see below or read
> /usr/share/doc/grep/NEWS after installation; for complete details see:
> 
> 	/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
> 	...
> 
> Other usages documented below also now generate stderr warning or
> error messages.
> 
> This is a test release due to those breaking interface changes, and
> will not be released as current stable for a few weeks, once we
> understand any impact on current packages and systems.
> 
> All users worried about breakage should install this package in a test
> environment and validate whether it breaks their current systems.
> 
> Package maintainers should check that their installed packages and
> scripts do not generate, issue, or use the deprecated obsolescent
> commands or features, and any impacts on their future builds.
> Many configure, ltmain.sh, and test scripts contain egrep tests
> that may produce stderr warning messages.
> So far, I have only seen egrep warning messages from *cygport*.
> Please let me know directly if any of your packages are impacted,
> and you can not mitigate any impacts in a few weeks, and how long
> until you expect to be able to mitigate any impacts.
> Please also CC cygwin-apps for others, as my ISP has blocked it!
> 
> 
> Noteworthy changes in release 3.8 (2022-09-02) [stable]
> 
> Changes in behavior
> 
> * The -P option is now based on PCRE2 instead of the older PCRE,
>    thanks to code contributed by Carlo Arenas.
> 
> * The egrep and fgrep commands, which have been deprecated since
>    release 2.5.3 (2007), now warn that they are obsolescent and should
>    be replaced by grep -E and grep -F.
> 
> * The confusing GREP_COLOR environment variable is now obsolescent.
>    Instead of GREP_COLOR='xxx', use GREP_COLORS='mt=xxx'. grep now
>    warns if GREP_COLOR is used and is not overridden by GREP_COLORS.
>    Also, grep now treats GREP_COLOR like GREP_COLORS by silently
>    ignoring it if it attempts to inject ANSI terminal escapes.
> 
> * Regular expressions with stray backslashes now cause warnings, as
>    their unspecified behavior can lead to unexpected results.
>    For example, '\a' and 'a' are not always equivalent.
>    Similarly, regular expressions or subexpressions that start with a
>    repetition operator now also cause warnings due to their unspecified
>    behavior; for example, *a(+b|{1}c) now has three reasons to warn.
>    The warnings are intended as a transition aid; they are likely to be
>    errors in future releases.
> 
> * Regular expressions like [:space:] are now errors even if
>    POSIXLY_CORRECT is set, since POSIX now allows the GNU behavior.
> 
> Bug fixes
> 
> * In locales using UTF-8 encoding, the regular expression '.' no
>    longer sometimes fails to match Unicode characters U+D400 through
>    U+D7FF (some Hangul Syllables, and Hangul Jamo Extended-B) and
>    Unicode characters U+108000 through U+10FFFF (half of Supplemental
>    Private Use Area plane B).
>    [bug introduced in grep 3.4]
> 
> * The -s option no longer suppresses "binary file matches" messages.
>    [Bug#51860 introduced in grep 3.5]
> 
> Documentation improvements
> 
> * The manual now covers unspecified behavior in patterns like \x, (+),
>    and range expressions outside the POSIX locale.


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  2022-09-29 18:55 ` [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable Brian Inglis
@ 2022-10-27 16:25   ` Corinna Vinschen
  2022-10-28  6:49     ` Brian Inglis
  0 siblings, 1 reply; 19+ messages in thread
From: Corinna Vinschen @ 2022-10-27 16:25 UTC (permalink / raw)
  To: Brian Inglis; +Cc: Cygwin Applications

Hi Brian,

On Sep 29 12:55, Brian Inglis wrote:
> Hi folks, [Please Reply All as ISP blocking Cygwin lists]
> [...]
> > 	/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.


Thanks,
Corinna

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  2022-10-27 16:25   ` Corinna Vinschen
@ 2022-10-28  6:49     ` Brian Inglis
  2022-10-28  8:13       ` Corinna Vinschen
  2022-10-28 12:40       ` gs-cygwin.com
  0 siblings, 2 replies; 19+ messages in thread
From: Brian Inglis @ 2022-10-28  6:49 UTC (permalink / raw)
  To: cygwin-apps; +Cc: Brian.Inglis

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

and these issues were SlashDotted then:

https://news.slashdot.org/story/22/09/05/0135254/gnu-grep-38-starts-issuing-warnings-about-using-egrep-and-fgrep

https://inbox.sourceware.org/cygwin-announce/20220904140803.17862-1-Brian.Inglis@SystematicSW.ab.ca/

https://inbox.sourceware.org/cygwin-apps/021f494d-dac8-12b2-b49d-7bf6d56068a4@SystematicSw.ab.ca/

https://inbox.sourceware.org/cygwin-announce/20221002155559.36122-1-Brian.Inglis@SystematicSW.ab.ca/

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 will not be suprised if Paul enforces these changes in the next release, in 
about a year.

-- 
Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada

La perfection est atteinte			Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter	not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer	but when there is no more to cut
			-- Antoine de Saint-Exupéry

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  2022-10-28  6:49     ` Brian Inglis
@ 2022-10-28  8:13       ` Corinna Vinschen
  2022-10-28  8:20         ` Corinna Vinschen
  2022-10-28 12:40       ` gs-cygwin.com
  1 sibling, 1 reply; 19+ messages in thread
From: Corinna Vinschen @ 2022-10-28  8:13 UTC (permalink / raw)
  To: cygwin-apps

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  2022-10-28  8:13       ` Corinna Vinschen
@ 2022-10-28  8:20         ` Corinna Vinschen
  2022-10-28 13:36           ` Thomas Wolff
  0 siblings, 1 reply; 19+ messages in thread
From: Corinna Vinschen @ 2022-10-28  8:20 UTC (permalink / raw)
  To: cygwin-apps

On Oct 28 10:13, Corinna Vinschen wrote:
> 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.

Oh, and the BSDs will very certainly keep egrep and fgrep forever,
without the dreaded warnings...

I don't even understand why they are so "bad" that they have to be
removed.  What a weird idea.


Corinna

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  2022-10-28  6:49     ` Brian Inglis
  2022-10-28  8:13       ` Corinna Vinschen
@ 2022-10-28 12:40       ` gs-cygwin.com
  2022-10-28 14:29         ` Corinna Vinschen
  2022-11-03 18:08         ` Brian Inglis
  1 sibling, 2 replies; 19+ messages in thread
From: gs-cygwin.com @ 2022-10-28 12:40 UTC (permalink / raw)
  To: cygwin-apps

On Fri, Oct 28, 2022 at 12:49:37AM -0600, 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:

Planning for the future, could the grep package provide egrep and fgrep
in /etc/alternatives?  Then a new (optional) package, say "grepfe" could
provide /etc/alternative shell scripts (or binaries) which called
grep -F and grep -E.

Cheers, Glenn

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  2022-10-28  8:20         ` Corinna Vinschen
@ 2022-10-28 13:36           ` Thomas Wolff
  2022-11-19 20:26             ` Brian Inglis
  0 siblings, 1 reply; 19+ messages in thread
From: Thomas Wolff @ 2022-10-28 13:36 UTC (permalink / raw)
  To: cygwin-apps



Am 28/10/2022 um 10:20 schrieb Corinna Vinschen:
> On Oct 28 10:13, Corinna Vinschen wrote:
>> 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.
> Oh, and the BSDs will very certainly keep egrep and fgrep forever,
> without the dreaded warnings...
>
> I don't even understand why they are so "bad" that they have to be
> removed.  What a weird idea.
I agree so much. People should submit complaint issues upstream, the 
more the better.
It's only not so easy to find a way to submit a Gnu tool bug :(

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  2022-10-28 12:40       ` gs-cygwin.com
@ 2022-10-28 14:29         ` Corinna Vinschen
  2022-11-03 18:08         ` Brian Inglis
  1 sibling, 0 replies; 19+ messages in thread
From: Corinna Vinschen @ 2022-10-28 14:29 UTC (permalink / raw)
  To: cygwin-apps

On Oct 28 08:40, gs-cygwin.com@gluelogic.com wrote:
> On Fri, Oct 28, 2022 at 12:49:37AM -0600, 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:
> 
> Planning for the future, could the grep package provide egrep and fgrep
> in /etc/alternatives?  Then a new (optional) package, say "grepfe" could
> provide /etc/alternative shell scripts (or binaries) which called
> grep -F and grep -E.

That would be a feasible workaround.


Corinna

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  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
  1 sibling, 1 reply; 19+ messages in thread
From: Brian Inglis @ 2022-11-03 18:08 UTC (permalink / raw)
  To: cygwin-apps

> From: gs-cygwin.com@gluelogic.com
> To: cygwin-apps@cygwin.com
> Subject: Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
> Date: Fri, 28 Oct 2022 08:40:32 -0400	[thread overview]
> Message-ID: <Y1vNwOihsgDDrQBV@xps13> (raw)
> In-Reply-To: <f8a59249-1090-9136-c720-6e096bc3b7a8@SystematicSw.ab.ca>
> 
> On Fri, Oct 28, 2022 at 12:49:37AM -0600, 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:
> 
> Planning for the future, could the grep package provide egrep and fgrep
> in /etc/alternatives?  Then a new (optional) package, say "grepfe" could
> provide /etc/alternative shell scripts (or binaries) which called
> grep -F and grep -E.

Suggest that I could come up with a package grep-nowarn which can only suppress 
the [ef]grep warnings, where the package would install [ef]grep-nowarn, and the 
postinstall script could rename the distributed shell scripts to [ef]grep-warn, 
and install alternatives with -warn priority 10, -nowarn priority 20; preremove 
would reverse the process.

Suggestions to accommodate -nowarn from grep package postinstall?
I could supply the same postinstall and preremove as -nowarn to check for 
-nowarn and install or uninstall the alternative.

Sequence or timing issues to watch out for during postinstall/preremove?

-- 
Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada

La perfection est atteinte			Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter	not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer	but when there is no more to cut
			-- Antoine de Saint-Exupéry

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  2022-11-03 18:08         ` Brian Inglis
@ 2022-11-03 18:31           ` Achim Gratz
  2022-11-04  0:09             ` Richard H. Gumpertz
                               ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Achim Gratz @ 2022-11-03 18:31 UTC (permalink / raw)
  To: cygwin-apps

Brian Inglis writes:
> Suggest that I could come up with a package grep-nowarn which can only
> suppress the [ef]grep warnings, where the package would install
> [ef]grep-nowarn, and the postinstall script could rename the
> distributed shell scripts to [ef]grep-warn, and install alternatives
> with -warn priority 10, -nowarn priority 20; preremove would reverse
> the process.
>
> Suggestions to accommodate -nowarn from grep package postinstall?
> I could supply the same postinstall and preremove as -nowarn to check
> for -nowarn and install or uninstall the alternative.
>
> Sequence or timing issues to watch out for during postinstall/preremove?

As Corinna already said, why GNU suddenly cares so much about strict
POSIX conformance in this case is puzzling.  If anything they should
have left the decision to packagers and IMNHO the warning should only be
presented when POSIXLY_CORRECT is set in the environment, if at all.
The patch to the wrapper script(s) in question is trivial and several
Linux distributions have removed the warning already (if you do this,
also change the interpreter from bash to dash).  Just skip any
extra packages and do the same.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  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
  2 siblings, 0 replies; 19+ messages in thread
From: Richard H. Gumpertz @ 2022-11-04  0:09 UTC (permalink / raw)
  To: Achim Gratz, cygwin-apps

I don't care how you do it, but utilities that have been around since 
the beginning of time should NEVER go away!  Nor should changes to them 
they break existing, working, scripts.  Deprecate them in man pages if 
you want, but don't ever break things that work unless so doing has a 
GIANT payback by allowing something else to get better.

                 Rick Gumpertz

On 11/3/2022 11:31, Achim Gratz wrote:
> Brian Inglis writes:
>> Suggest that I could come up with a package grep-nowarn which can only
>> suppress the [ef]grep warnings, where the package would install
>> [ef]grep-nowarn, and the postinstall script could rename the
>> distributed shell scripts to [ef]grep-warn, and install alternatives
>> with -warn priority 10, -nowarn priority 20; preremove would reverse
>> the process.
>>
>> Suggestions to accommodate -nowarn from grep package postinstall?
>> I could supply the same postinstall and preremove as -nowarn to check
>> for -nowarn and install or uninstall the alternative.
>>
>> Sequence or timing issues to watch out for during postinstall/preremove?
> As Corinna already said, why GNU suddenly cares so much about strict
> POSIX conformance in this case is puzzling.  If anything they should
> have left the decision to packagers and IMNHO the warning should only be
> presented when POSIXLY_CORRECT is set in the environment, if at all.
> The patch to the wrapper script(s) in question is trivial and several
> Linux distributions have removed the warning already (if you do this,
> also change the interpreter from bash to dash).  Just skip any
> extra packages and do the same.
>
>
> Regards,
> Achim.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  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
  2 siblings, 0 replies; 19+ messages in thread
From: Corinna Vinschen @ 2022-11-04 12:47 UTC (permalink / raw)
  To: cygwin-apps

On Nov  3 19:31, Achim Gratz wrote:
> Brian Inglis writes:
> > Suggest that I could come up with a package grep-nowarn which can only
> > suppress the [ef]grep warnings, where the package would install
> > [ef]grep-nowarn, and the postinstall script could rename the
> > distributed shell scripts to [ef]grep-warn, and install alternatives
> > with -warn priority 10, -nowarn priority 20; preremove would reverse
> > the process.
> >
> > Suggestions to accommodate -nowarn from grep package postinstall?
> > I could supply the same postinstall and preremove as -nowarn to check
> > for -nowarn and install or uninstall the alternative.
> >
> > Sequence or timing issues to watch out for during postinstall/preremove?
> 
> As Corinna already said, why GNU suddenly cares so much about strict
> POSIX conformance in this case is puzzling.  If anything they should
> have left the decision to packagers and IMNHO the warning should only be
> presented when POSIXLY_CORRECT is set in the environment, if at all.
> The patch to the wrapper script(s) in question is trivial and several
> Linux distributions have removed the warning already (if you do this,
> also change the interpreter from bash to dash).  Just skip any
> extra packages and do the same.

+1


Corinna

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  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
  2 siblings, 1 reply; 19+ messages in thread
From: Brian Inglis @ 2022-11-04 19:07 UTC (permalink / raw)
  To: cygwin-apps

On Thu, 03 Nov 2022 19:31:27 +0100, Achim Gratz wrote:
> Brian Inglis writes:
>> Suggest that I could come up with a package grep-nowarn which can only
>> suppress the [ef]grep warnings, where the package would install
>> [ef]grep-nowarn, and the postinstall script could rename the
>> distributed shell scripts to [ef]grep-warn, and install alternatives
>> with -warn priority 10, -nowarn priority 20; preremove would reverse
>> the process.
>>
>> Suggestions to accommodate -nowarn from grep package postinstall?
>> I could supply the same postinstall and preremove as -nowarn to check
>> for -nowarn and install or uninstall the alternative.
>>
>> Sequence or timing issues to watch out for during postinstall/preremove?

> As Corinna already said, why GNU suddenly cares so much about strict
> POSIX conformance in this case is puzzling.  If anything they should
> have left the decision to packagers and IMNHO the warning should only be
> presented when POSIXLY_CORRECT is set in the environment, if at all.
> The patch to the wrapper script(s) in question is trivial and several
> Linux distributions have removed the warning already (if you do this,
> also change the interpreter from bash to dash).  Just skip any
> extra packages and do the same.

The issue does not appear to be about POSIX compliance, but that [ef]grep were 
dropped from POSIX before 2008 and declared obsolescent, so the maintainers 
appear to be looking to drop those commands/scripts.

You could perhaps reach out to Eric Blake or Jim Meyering who are in the GNU 
grep contributor lists for rationale.

While Debian and OpenSuSE have reverted that change, Fedora has not in main or 
rawhide.

-- 
Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada

La perfection est atteinte			Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter	not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer	but when there is no more to cut
			-- Antoine de Saint-Exupéry

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  2022-11-04 19:07             ` Brian Inglis
@ 2022-11-04 19:27               ` Corinna Vinschen
  2022-11-13 17:09                 ` Thomas Wolff
  0 siblings, 1 reply; 19+ messages in thread
From: Corinna Vinschen @ 2022-11-04 19:27 UTC (permalink / raw)
  To: cygwin-apps

On Nov  4 13:07, Brian Inglis wrote:
> On Thu, 03 Nov 2022 19:31:27 +0100, Achim Gratz wrote:
> > Brian Inglis writes:
> > > Suggest that I could come up with a package grep-nowarn which can only
> > > suppress the [ef]grep warnings, where the package would install
> > > [ef]grep-nowarn, and the postinstall script could rename the
> > > distributed shell scripts to [ef]grep-warn, and install alternatives
> > > with -warn priority 10, -nowarn priority 20; preremove would reverse
> > > the process.
> > > 
> > > Suggestions to accommodate -nowarn from grep package postinstall?
> > > I could supply the same postinstall and preremove as -nowarn to check
> > > for -nowarn and install or uninstall the alternative.
> > > 
> > > Sequence or timing issues to watch out for during postinstall/preremove?
> 
> > As Corinna already said, why GNU suddenly cares so much about strict
> > POSIX conformance in this case is puzzling.  If anything they should
> > have left the decision to packagers and IMNHO the warning should only be
> > presented when POSIXLY_CORRECT is set in the environment, if at all.
> > The patch to the wrapper script(s) in question is trivial and several
> > Linux distributions have removed the warning already (if you do this,
> > also change the interpreter from bash to dash).  Just skip any
> > extra packages and do the same.
> 
> The issue does not appear to be about POSIX compliance, but that [ef]grep
> were dropped from POSIX before 2008 and declared obsolescent, so the
> maintainers appear to be looking to drop those commands/scripts.

This is a usability issue.  If upstream thinks they have to do such a
potentially destructive and backward-incompatible change for no other
reason than "is not in POSIX", they can do so, but there's no good
reason the distros who *care* for usability have to do this either.

> 
> You could perhaps reach out to Eric Blake or Jim Meyering who are in the GNU
> grep contributor lists for rationale.
> 
> While Debian and OpenSuSE have reverted that change, Fedora has not in main
> or rawhide.

Right, Debian and OpenSuSE revert the change and the BSDs will not break
e/fgrep either, obviously.  I doubt Ubuntu will do that.  Fedora often
values progress, for a given value of "progress", higher than usability.
They will probably see lots of Bugzillas and user requests in other
forums due to this change and then ignore them.  But that doesn't mean
we have to do it.

Again: Egrep and fgrep are used in lots of scripts around the world.  A
change like this will have a massive impact for years to come.

So, again, in the name of usability, let's follow Debian and OpenSuSE
here, not Fedora, please.


Corinna

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  2022-11-04 19:27               ` Corinna Vinschen
@ 2022-11-13 17:09                 ` Thomas Wolff
  2022-11-13 22:13                   ` Brian Inglis
  0 siblings, 1 reply; 19+ messages in thread
From: Thomas Wolff @ 2022-11-13 17:09 UTC (permalink / raw)
  To: cygwin-apps, Brian Inglis



Am 04.11.2022 um 20:27 schrieb Corinna Vinschen:
> On Nov  4 13:07, Brian Inglis wrote:
>> On Thu, 03 Nov 2022 19:31:27 +0100, Achim Gratz wrote:
>>> Brian Inglis writes:
>>>> Suggest that I could come up with a package grep-nowarn which can only
>>>> suppress the [ef]grep warnings, where the package would install
>>>> [ef]grep-nowarn, and the postinstall script could rename the
>>>> distributed shell scripts to [ef]grep-warn, and install alternatives
>>>> with -warn priority 10, -nowarn priority 20; preremove would reverse
>>>> the process.
>>>>
>>>> Suggestions to accommodate -nowarn from grep package postinstall?
>>>> I could supply the same postinstall and preremove as -nowarn to check
>>>> for -nowarn and install or uninstall the alternative.
>>>>
>>>> Sequence or timing issues to watch out for during postinstall/preremove?
>>> As Corinna already said, why GNU suddenly cares so much about strict
>>> POSIX conformance in this case is puzzling.  If anything they should
>>> have left the decision to packagers and IMNHO the warning should only be
>>> presented when POSIXLY_CORRECT is set in the environment, if at all.
>>> The patch to the wrapper script(s) in question is trivial and several
>>> Linux distributions have removed the warning already (if you do this,
>>> also change the interpreter from bash to dash).  Just skip any
>>> extra packages and do the same.
>> The issue does not appear to be about POSIX compliance, but that [ef]grep
>> were dropped from POSIX before 2008 and declared obsolescent, so the
>> maintainers appear to be looking to drop those commands/scripts.
> This is a usability issue.  If upstream thinks they have to do such a
> potentially destructive and backward-incompatible change for no other
> reason than "is not in POSIX", they can do so, but there's no good
> reason the distros who *care* for usability have to do this either.
>
>> You could perhaps reach out to Eric Blake or Jim Meyering who are in the GNU
>> grep contributor lists for rationale.
>>
>> While Debian and OpenSuSE have reverted that change, Fedora has not in main
>> or rawhide.
> Right, Debian and OpenSuSE revert the change and the BSDs will not break
> e/fgrep either, obviously.  I doubt Ubuntu will do that.  Fedora often
> values progress, for a given value of "progress", higher than usability.
> They will probably see lots of Bugzillas and user requests in other
> forums due to this change and then ignore them.  But that doesn't mean
> we have to do it.
>
> Again: Egrep and fgrep are used in lots of scripts around the world.  A
> change like this will have a massive impact for years to come.
>
> So, again, in the name of usability, let's follow Debian and OpenSuSE
> here, not Fedora, please.
@Brian, as a grep package maintainer, can you *please* make a trivial 
patch to remove the grep crap as Corinna suggested and upload an updated 
package *today*, as Jon Turney threatens to freeze the x86 repository 
tomorrow?


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  2022-11-13 17:09                 ` Thomas Wolff
@ 2022-11-13 22:13                   ` Brian Inglis
  2022-11-14  5:21                     ` Thomas Wolff
  0 siblings, 1 reply; 19+ messages in thread
From: Brian Inglis @ 2022-11-13 22:13 UTC (permalink / raw)
  To: cygwin-apps

On Sun, 13 Nov 2022 18:09:19 +0100, Thomas Wolff wrote:
> Am 04.11.2022 um 20:27 schrieb Corinna Vinschen:
>> On Nov  4 13:07, Brian Inglis wrote:
>>> On Thu, 03 Nov 2022 19:31:27 +0100, Achim Gratz wrote:
>>>> Brian Inglis writes:
>>>>> Suggest that I could come up with a package grep-nowarn which can only
>>>>> suppress the [ef]grep warnings, where the package would install
>>>>> [ef]grep-nowarn, and the postinstall script could rename the
>>>>> distributed shell scripts to [ef]grep-warn, and install alternatives
>>>>> with -warn priority 10, -nowarn priority 20; preremove would reverse
>>>>> the process.
>>>>>
>>>>> Suggestions to accommodate -nowarn from grep package postinstall?
>>>>> I could supply the same postinstall and preremove as -nowarn to check
>>>>> for -nowarn and install or uninstall the alternative.
>>>>>
>>>>> Sequence or timing issues to watch out for during postinstall/preremove?
>>>> As Corinna already said, why GNU suddenly cares so much about strict
>>>> POSIX conformance in this case is puzzling.  If anything they should
>>>> have left the decision to packagers and IMNHO the warning should only be
>>>> presented when POSIXLY_CORRECT is set in the environment, if at all.
>>>> The patch to the wrapper script(s) in question is trivial and several
>>>> Linux distributions have removed the warning already (if you do this,
>>>> also change the interpreter from bash to dash).  Just skip any
>>>> extra packages and do the same.
>>> The issue does not appear to be about POSIX compliance, but that [ef]grep
>>> were dropped from POSIX before 2008 and declared obsolescent, so the
>>> maintainers appear to be looking to drop those commands/scripts.
>> This is a usability issue.  If upstream thinks they have to do such a
>> potentially destructive and backward-incompatible change for no other
>> reason than "is not in POSIX", they can do so, but there's no good
>> reason the distros who *care* for usability have to do this either.
>>
>>> You could perhaps reach out to Eric Blake or Jim Meyering who are in the GNU
>>> grep contributor lists for rationale.
>>>
>>> While Debian and OpenSuSE have reverted that change, Fedora has not in main
>>> or rawhide.
>> Right, Debian and OpenSuSE revert the change and the BSDs will not break
>> e/fgrep either, obviously.  I doubt Ubuntu will do that.  Fedora often
>> values progress, for a given value of "progress", higher than usability.
>> They will probably see lots of Bugzillas and user requests in other
>> forums due to this change and then ignore them.  But that doesn't mean
>> we have to do it.
>>
>> Again: Egrep and fgrep are used in lots of scripts around the world.  A
>> change like this will have a massive impact for years to come.
>>
>> So, again, in the name of usability, let's follow Debian and OpenSuSE
>> here, not Fedora, please.

> @Brian, as a grep package maintainer, can you *please* make a trivial 
> patch to remove the grep crap as Corinna suggested and upload an updated 
> package *today*, as Jon Turney threatens to freeze the x86 repository 
> tomorrow?

Successfully deployed from Scallywag and announced.

-- 
Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada

La perfection est atteinte			Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter	not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer	but when there is no more to cut
			-- Antoine de Saint-Exupéry

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  2022-11-13 22:13                   ` Brian Inglis
@ 2022-11-14  5:21                     ` Thomas Wolff
  0 siblings, 0 replies; 19+ messages in thread
From: Thomas Wolff @ 2022-11-14  5:21 UTC (permalink / raw)
  To: cygwin-apps



Am 13.11.2022 um 23:13 schrieb Brian Inglis:
> On Sun, 13 Nov 2022 18:09:19 +0100, Thomas Wolff wrote:
>> Am 04.11.2022 um 20:27 schrieb Corinna Vinschen:
>>> On Nov  4 13:07, Brian Inglis wrote:
>>>> On Thu, 03 Nov 2022 19:31:27 +0100, Achim Gratz wrote:
>>>>> Brian Inglis writes:
>>>>>> Suggest that I could come up with a package grep-nowarn which can 
>>>>>> only
>>>>>> suppress the [ef]grep warnings, where the package would install
>>>>>> [ef]grep-nowarn, and the postinstall script could rename the
>>>>>> distributed shell scripts to [ef]grep-warn, and install alternatives
>>>>>> with -warn priority 10, -nowarn priority 20; preremove would reverse
>>>>>> the process.
>>>>>>
>>>>>> Suggestions to accommodate -nowarn from grep package postinstall?
>>>>>> I could supply the same postinstall and preremove as -nowarn to 
>>>>>> check
>>>>>> for -nowarn and install or uninstall the alternative.
>>>>>>
>>>>>> Sequence or timing issues to watch out for during 
>>>>>> postinstall/preremove?
>>>>> As Corinna already said, why GNU suddenly cares so much about strict
>>>>> POSIX conformance in this case is puzzling.  If anything they should
>>>>> have left the decision to packagers and IMNHO the warning should 
>>>>> only be
>>>>> presented when POSIXLY_CORRECT is set in the environment, if at all.
>>>>> The patch to the wrapper script(s) in question is trivial and several
>>>>> Linux distributions have removed the warning already (if you do this,
>>>>> also change the interpreter from bash to dash).  Just skip any
>>>>> extra packages and do the same.
>>>> The issue does not appear to be about POSIX compliance, but that 
>>>> [ef]grep
>>>> were dropped from POSIX before 2008 and declared obsolescent, so the
>>>> maintainers appear to be looking to drop those commands/scripts.
>>> This is a usability issue.  If upstream thinks they have to do such a
>>> potentially destructive and backward-incompatible change for no other
>>> reason than "is not in POSIX", they can do so, but there's no good
>>> reason the distros who *care* for usability have to do this either.
>>>
>>>> You could perhaps reach out to Eric Blake or Jim Meyering who are 
>>>> in the GNU
>>>> grep contributor lists for rationale.
>>>>
>>>> While Debian and OpenSuSE have reverted that change, Fedora has not 
>>>> in main
>>>> or rawhide.
>>> Right, Debian and OpenSuSE revert the change and the BSDs will not 
>>> break
>>> e/fgrep either, obviously.  I doubt Ubuntu will do that. Fedora often
>>> values progress, for a given value of "progress", higher than 
>>> usability.
>>> They will probably see lots of Bugzillas and user requests in other
>>> forums due to this change and then ignore them.  But that doesn't mean
>>> we have to do it.
>>>
>>> Again: Egrep and fgrep are used in lots of scripts around the world.  A
>>> change like this will have a massive impact for years to come.
>>>
>>> So, again, in the name of usability, let's follow Debian and OpenSuSE
>>> here, not Fedora, please.
>
>> @Brian, as a grep package maintainer, can you *please* make a trivial 
>> patch to remove the grep crap as Corinna suggested and upload an 
>> updated package *today*, as Jon Turney threatens to freeze the x86 
>> repository tomorrow?
>
> Successfully deployed from Scallywag and announced.
>
Great! Thank you very much.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
  2022-10-28 13:36           ` Thomas Wolff
@ 2022-11-19 20:26             ` Brian Inglis
  0 siblings, 0 replies; 19+ messages in thread
From: Brian Inglis @ 2022-11-19 20:26 UTC (permalink / raw)
  To: cygwin-apps

On Fri, 28 Oct 2022 15:36:30 +0200, Thomas Wolff wrote:
> Am 28/10/2022 um 10:20 schrieb Corinna Vinschen:
>> On Oct 28 10:13, Corinna Vinschen wrote:
>>> 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:
...
> I agree so much. People should submit complaint issues upstream, the 
> more the better.
> It's only not so easy to find a way to submit a Gnu tool bug :(

Always easy with GNU mailto:bug-grep@gnu.org

Archives at https://lists.gnu.org/archive/html/bug-grep/

- see long September and October threads:

https://lists.gnu.org/archive/html/bug-grep/2022-09/threads.html
https://lists.gnu.org/archive/html/bug-grep/2022-10/threads.html

In general for GNU packages:

project		@ https://sv.gnu.org/p/PKG
home page	@ https://gnu.org/s/PKG
docs		@ https://gnu.org/s/PKG/manual/
MLs		@ https://lists.gnu.org/archive/html/bug-PKG/
bugs		@ mailto:bug-PKG@gnu.org

-- 
Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada

La perfection est atteinte			Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter	not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer	but when there is no more to cut
			-- Antoine de Saint-Exupéry

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable
@ 2022-11-13 21:06 Brian Inglis
  0 siblings, 0 replies; 19+ messages in thread
From: Brian Inglis @ 2022-11-13 21:06 UTC (permalink / raw)
  To: cygwin-apps

On 2022-11-13 10:09, Thomas Wolff wrote:
> Am 04.11.2022 um 20:27 schrieb Corinna Vinschen:
>> On Nov  4 13:07, Brian Inglis wrote:
>>> On Thu, 03 Nov 2022 19:31:27 +0100, Achim Gratz wrote:
>>>> Brian Inglis writes:
>>>>> Suggest that I could come up with a package grep-nowarn which can only
>>>>> suppress the [ef]grep warnings, where the package would install
>>>>> [ef]grep-nowarn, and the postinstall script could rename the
>>>>> distributed shell scripts to [ef]grep-warn, and install alternatives
>>>>> with -warn priority 10, -nowarn priority 20; preremove would reverse
>>>>> the process.
>>>>>
>>>>> Suggestions to accommodate -nowarn from grep package postinstall?
>>>>> I could supply the same postinstall and preremove as -nowarn to check
>>>>> for -nowarn and install or uninstall the alternative.
>>>>>
>>>>> Sequence or timing issues to watch out for during postinstall/preremove?
>>>> As Corinna already said, why GNU suddenly cares so much about strict
>>>> POSIX conformance in this case is puzzling.  If anything they should
>>>> have left the decision to packagers and IMNHO the warning should only be
>>>> presented when POSIXLY_CORRECT is set in the environment, if at all.
>>>> The patch to the wrapper script(s) in question is trivial and several
>>>> Linux distributions have removed the warning already (if you do this,
>>>> also change the interpreter from bash to dash).  Just skip any
>>>> extra packages and do the same.
>>> The issue does not appear to be about POSIX compliance, but that [ef]grep
>>> were dropped from POSIX before 2008 and declared obsolescent, so the
>>> maintainers appear to be looking to drop those commands/scripts.
>> This is a usability issue.  If upstream thinks they have to do such a
>> potentially destructive and backward-incompatible change for no other
>> reason than "is not in POSIX", they can do so, but there's no good
>> reason the distros who *care* for usability have to do this either.
>>
>>> You could perhaps reach out to Eric Blake or Jim Meyering who are in the GNU
>>> grep contributor lists for rationale.
>>>
>>> While Debian and OpenSuSE have reverted that change, Fedora has not in main
>>> or rawhide.
>> Right, Debian and OpenSuSE revert the change and the BSDs will not break
>> e/fgrep either, obviously.  I doubt Ubuntu will do that.  Fedora often
>> values progress, for a given value of "progress", higher than usability.
>> They will probably see lots of Bugzillas and user requests in other
>> forums due to this change and then ignore them.  But that doesn't mean
>> we have to do it.
>>
>> Again: Egrep and fgrep are used in lots of scripts around the world.  A
>> change like this will have a massive impact for years to come.
>>
>> So, again, in the name of usability, let's follow Debian and OpenSuSE
>> here, not Fedora, please.

> @Brian, as a grep package maintainer, can you *please* make a trivial patch to 
> remove the grep crap as Corinna suggested and upload an updated package *today*, 
> as Jon Turney threatens to freeze the x86 repository tomorrow?

I am trying to do so, but getting weird test artifacts locally, so retrying in 
hopes that they will complete normally.

If there are still issues, I will look at deploying from Scallywag, as those 
builds completed cleanly.

I am also trying to clean up a couple of other package issues, and hopefully 
don't mess up anything else trying to get these done without any time for actual 
use.
My system is fully loaded running only a single build, and each can take over an 
hour, about the same time as Scallywag, but without any arch parallelism.

[Being the weekend, there are also other things to do and people to see.]

-- 
Take care. Thanks, Brian Inglis			Calgary, Alberta, Canada

La perfection est atteinte			Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter	not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer	but when there is no more to cut
			-- Antoine de Saint-Exupéry

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2022-11-19 20:26 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <announce.20220904140803.17862-1-Brian.Inglis@SystematicSW.ab.ca>
2022-09-29 18:55 ` [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable Brian Inglis
2022-10-27 16:25   ` Corinna Vinschen
2022-10-28  6:49     ` Brian Inglis
2022-10-28  8:13       ` Corinna Vinschen
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

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).