A NOTE has been added to this issue. 
====================================================================== 
https://www.austingroupbugs.net/view.php?id=1941 
====================================================================== 
Reported By:                dwheeler
Assigned To:                ajosey
====================================================================== 
Project:                    1003.1(2024)/Issue8
Issue ID:                   1941
Category:                   Shell and Utilities
Type:                       Enhancement Request
Severity:                   Objection
Priority:                   normal
Status:                     Under Review
Name:                       David A. Wheeler 
Organization:                
User Reference:              
Section:                    grep 
Page Number:                1 
Line Number:                1 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2025-08-30 21:51 UTC
Last Modified:              2025-09-11 18:01 UTC
====================================================================== 
Summary:                    Add widely-implemented options to grep
====================================================================== 

---------------------------------------------------------------------- 
 (0007256) dwheeler (reporter) - 2025-09-11 18:01
 https://www.austingroupbugs.net/view.php?id=1941#c7256 
---------------------------------------------------------------------- 
I was asked to do some research; below are my results. In summary:

* Oracle Solaris implements some of these grep options.
  It doesn't implement some, but there are no flag conflicts and
  it should be easy to implement them.
* MirBSD has some incompatibilities. However, this is a niche hobby project
  that self-describes as "not suitable for installation" and only supports
  obsolete chips (32-bit i386 and sparc). It has incompatible -H and -o
  options. I think that should NOT hold back POSIX. Let's standardize
  on what MacOS, GNU/Linux, FreeBSD, BusyBox, and all agree on.
* Regarding -C ("context"): A -Cnum option *might* work across existing
  implementations. I'll investigate further; if anyone knows anything about
this,
  please speak up.
* I will separately collect the tweaks (based on feedback) to create an
  updated proposal, formatted using HTML instead of Markdown. However, I want
  to track down information on -C first.

First, regarding Oracle (nee Sun) Solaris:
The documentation on its grep implementation appears to be here
(this is for version 11.4, which appears to be the current version):
https://docs.oracle.com/cd/E88353_01/html/E37839/grep-1.html

Solaris grep already supports, with the same semantics:

-G: Interpret patterns as basic regular expressions (this is already the default
behavior in Solaris)
-h: Suppress the prefixing of file names on output. This is the default when
there is only one file (or only standard input) to search. See the -H option.

Solaris grep does NOT support, and has no conflicting flags, for:

-A NUM: Print NUM lines of context after each match
-B NUM: Print NUM lines of context before each match
-H: Print the file name for each selection (force filename display)
-L: List names of files that were processed but no lines were selected
-m NUM: Stop reading after NUM selections
-o: Display only the selected (non-empty) parts of matching lines
-C NUM: -A NUM and -B NUM [not in original proposal]

There's no conflict, and these should all be really easy to implement
in an existing implementation.



Regarding MirBSD ("mirabilos’ Open Source playground):
As they explain in http://www.mirbsd.org/about.htm -
"MirOS BSD is a niche operating system from the BSD family for 32-bit i386
and sparc systems. It is based on 4.4BSD-Lite (mostly OpenBSD, some NetBSD®)...
MirBSD pretty much is a hobby project with interesting side projects
and subprojects in wide use (such as mksh), but which by itself…
is not suitable for installation, except by people actually wanting to work on
it."

I don't think POSIX should be beholden to MirBSD. It's self-described as
a hobby project "not suitable for installation" and focused on obsolete chips.
32-bit i386 chips are no longer even being made. SPARC chips are made but new
work has been discontinued & there's a general transition away from them.

For completeness,
I reviewed MirBSD grep docs here: http://www.mirbsd.org/man.cgi?q=grep#direct

MirBSD already supports, with the same semantics:

-A NUM: Print NUM lines of context after each match
-B NUM: Print NUM lines of context before each match
-L: List names of files that were processed but no lines were selected.
    Pathnames are listed once per file searched.
    If the standard input is searched, the string "(standard input)"
    is written.

It also supports:
-C[num] : -A and -B. No whitespace may be given between option and argument.
  Not in original proposal.


It does not support (but could add, since it has no incompatible flag):
-m NUM: Stop reading after NUM selections


There are two MirBSD incompatibilities:
-H      If -R is specified, follow symbolic links only if they were explicitly
        listed on the command line. The default is not to follow symbolic links.
vs. proposal:
-H: Print the file name for each selection (force filename display)

-o: Display only the selected (non-empty) parts of matching lines
vs. proposal
-o: Extract match


Regarding -C:
* On MacOS, "-C[num]" is supported. The num is *optional* (default 2), and
*must*
  be added *without* a space.
* On GNU, "-C NUM" is supported. The man page suggests NUM is required (not
optional).
  HOWEVER, it appears that in PRACTICE, GNU quietly implements -CNUM as well.
  (where there's no space after the number).
  So it might be possible to agree on an isolated "-Cnum" where there's no space
  after the "C". Handling this requires somewhat irregular option parsing, and I
haven't
  verified this works everywhere. Note that just "-C" without a number doesn't
work.
  I'm trying to investigate further, but it's hampered because this doesn't
appear to be
  well-documented. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2025-08-30 21:51 dwheeler       New Issue                                    
2025-08-30 21:51 dwheeler       Status                   New => Under Review 
2025-08-30 21:51 dwheeler       Assigned To               => ajosey          
2025-08-30 21:56 dwheeler       Note Added: 0007240                          
2025-08-30 21:59 dwheeler       Note Added: 0007241                          
2025-08-31 00:07 mirabilos      Note Added: 0007242                          
2025-08-31 00:10 mirabilos      Note Added: 0007243                          
2025-08-31 21:52 dwheeler       Note Added: 0007244                          
2025-08-31 22:01 dwheeler       Note Added: 0007245                          
2025-09-01 05:57 stephane       Note Added: 0007246                          
2025-09-01 06:05 stephane       Note Added: 0007247                          
2025-09-01 15:36 dwheeler       Note Added: 0007249                          
2025-09-01 17:10 dwheeler       Note Added: 0007250                          
2025-09-01 17:18 dwheeler       Note Added: 0007251                          
2025-09-11 15:31 lanodan        Note Added: 0007253                          
2025-09-11 15:36 lanodan        Note Edited: 0007253                         
2025-09-11 15:37 lanodan        Note Edited: 0007253                         
2025-09-11 15:37 lanodan        Note Edited: 0007253                         
2025-09-11 15:50 geoffclare     Project                  1003.1(2008)/Issue 7 =>
1003.1(2024)/Issue8
2025-09-11 18:01 dwheeler       Note Added: 0007256                          
======================================================================


  • [1003.1(20... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group

Reply via email to