A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1941 ====================================================================== Reported By: dwheeler Assigned To: ajosey ====================================================================== Project: 1003.1(2008)/Issue 7 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-01 15:36 UTC ====================================================================== Summary: Add widely-implemented options to grep ======================================================================
---------------------------------------------------------------------- (0007249) dwheeler (reporter) - 2025-09-01 15:36 https://austingroupbugs.net/view.php?id=1941#c7249 ---------------------------------------------------------------------- > Note that the reason those are widespread is that for the longest time BSDs actually shipped with GNU grep (some version thereof), many have since eventually re-implemented theirs trying to keep the GNU API, but sometimes diverging between themselves and from GNU grep after (and even before as they stayed on an older version of GNU grep) that point. That actually gives me hope - that makes it more likely we can gain more agreement on *some* things. Shared ancestry & compatibility gave us POSIX in the first place. > Recursive grep is very unportable in part because in GNU grep it has changed greatly over the years with regards to handling of symlinks and non-regular files. Divergences are hard to reconciliate now. -L/-H like in other recursive tools can't be used because they're used for other things in GNU grep, and anyway we'd need a third one for whether or not to process symlinks to regular files when doing a traversal that doesn't itself follow symlinks. As I noted, I didn't propose a recursive option in this issue. I do think it'd be possible to add one. In a lot of cases it's known there are no symlinks, so the difference is irrelevant, and options could be added to control "where it matters". But if you want to discuss recursive grep, let's take that up in a different issue where it's being proposed. > ast-open grep (which can also be made the grep builtin of ksh93, though I don't know whether there's any system where that's the case) is another grep implementation that has incorporated many of GNU grep's features (https://github.com/ksh93/ast-open-archive/blob/2014-12-24/src/lib/libcmd/grep.c#L23-L113). Its -o prints empty matches (a bug as it means it runs into infinite loops in that case). That's obviously a bug. We don't need to require bugs. Nobody else does that, and I can't imagine why anyone would want that. I can't imagine anyone *depending* on that behavior on a portable script, since that would fail in so many systems. Also, I'm sure nobody wants unintentional infinite loops :-). > -o would be more useful with an option to print what was matched by capture groups like in pcre2grep (formerly pcregrep)'s... > echo foobar | pcre2grep -o1 -o2 -o3 --om-separator=, '(.)(.)(.)' Printing capture groups does sound useful. I don't know an existing standard grep that supports printing capture groups, but if the spec added that *functionality* that'd be great. The syntax would have to be different. Nobody's current `-o` permits an optional parameter. Enabling an optional parameter would make existing scripts fail, e.g., `grep -oE...`. I can imagine something like -g NUMBER that can be repeated, each one causing the display of a captured group (in order requested). Another option could change the separator. However, I suggest that be a *separate* issue. Feel free to propose it! However, this issue was more about capturing options that are already in wide use in scripts that *already* work across a variety of systems. Creating an option not currently implemented by existing greps is obviously possible, but let's capture those discussions in separate groups :-). 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 ======================================================================
