A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1545 ====================================================================== Reported By: calestyo Assigned To: ====================================================================== Project: 1003.1(2016/18)/Issue7+TC2 Issue ID: 1545 Category: Shell and Utilities Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: Christoph Anton Mitterer Organization: User Reference: Section: sed utility Page Number: N/A Line Number: NA/ Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2022-01-08 03:22 UTC Last Modified: 2022-01-11 04:19 UTC ====================================================================== Summary: sed: standardise or at least reserve -E with sed for use of EREs ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- duplicate of 0000528 Support extended regular expressions (E... ======================================================================
---------------------------------------------------------------------- (0005595) philip-guenther (reporter) - 2022-01-11 04:19 https://austingroupbugs.net/view.php?id=1545#c5595 ---------------------------------------------------------------------- The standard can and does refer to other standards, using their *stable* identifiers. For example, Geoff's been spending a lot of time working out the details of updating the reference to the C standard to by C17. If an application compiles in the environment of the current POSIX standard and following its rules they get the version of C associated with that version. So, if there's a stable standard for the behavior of PCRE, then sure, POSIX could cite that and specify that grep/sed -P follow the behavior specified there. That would let applications authors request a precise behavior and if they didn't get it it would be a defect in the implementation, not their application. But you're explicitly denying the existence of a stable standard, "PCRE-2021", or maybe denying an interest in having applications adhere to such a thing if it does exist. How is an application author supposed to use or rely on that information? How is an implementation team supposed to know whether their particular version is "good enough" to abide? "So, there might be a -P option, and if it exists, it will presumably change the behavior of the regexp, but we can't tell you exactly how as that depends on what some 3rd party group decides. Well, two different 3rd party groups, because perl != PCRE and we don't say which. And yeah, an unmatched open-brace matched a literal open brace for 20+ years and then it became an error in some places, and then later more places, but not all, don't worry. Well, except for the other changes in behavior." The situation with BREs is that the behavior of the extensions is explicitly undefined per XBD 9.3.2 "BRE Ordinary Characters" and applications using them are not POSIX conformant; implementations can make them do whatever they want and there's no statement that they are reserved for the use that any particular tool has assigned. That's actually exactly the situation currently for the -P option to sed or grep: the behavior of sed or grep with that option is not defined by the standard and any application using that with them is not POSIX conformant; implementations can (and do!) make use of that to do what you desire. The goal of POSIX is "to support applications portability". How does 'reserving' -P for behavior that is not specified and *expected* to change support application portability? Do you not trust everyone involved to say "no, hell no" if POSIX contributors were to lose touch with the deployed environment and randomly specify sed/grep -P for some completely unrelated purpose? Issue History Date Modified Username Field Change ====================================================================== 2022-01-08 03:22 calestyo New Issue 2022-01-08 03:22 calestyo Name => Christoph Anton Mitterer 2022-01-08 03:22 calestyo Section => sed utility 2022-01-08 03:22 calestyo Page Number => N/A 2022-01-08 03:22 calestyo Line Number => NA/ 2022-01-10 09:19 geoffclare Note Added: 0005583 2022-01-10 09:19 geoffclare Relationship added duplicate of 0000528 2022-01-10 15:19 calestyo Note Added: 0005587 2022-01-10 15:56 geoffclare Note Added: 0005588 2022-01-10 21:34 stephane Note Added: 0005589 2022-01-10 22:22 calestyo Note Added: 0005590 2022-01-10 23:47 philip-guentherNote Added: 0005591 2022-01-11 00:24 calestyo Note Added: 0005593 2022-01-11 04:19 philip-guentherNote Added: 0005595 ======================================================================