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                          
======================================================================


  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to