A NOTE has been added to this issue. 
====================================================================== 
https://austingroupbugs.net/view.php?id=1556 
====================================================================== 
Reported By:                calestyo
Assigned To:                
====================================================================== 
Project:                    Issue 8 drafts
Issue ID:                   1556
Category:                   Shell and Utilities
Type:                       Clarification Requested
Severity:                   Objection
Priority:                   normal
Status:                     New
Name:                       Christoph Anton Mitterer 
Organization:                
User Reference:              
Section:                    Utilities, sed / 9.3.5 RE Bracket Expression 
Page Number:                - 
Line Number:                - 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2022-01-18 01:07 UTC
Last Modified:              2022-01-18 13:26 UTC
====================================================================== 
Summary:                    clarify meaning of \n used in a bracket expression
in a sed context address or s-command
====================================================================== 

---------------------------------------------------------------------- 
 (0005622) calestyo (reporter) - 2022-01-18 13:26
 https://austingroupbugs.net/view.php?id=1556#c5622 
---------------------------------------------------------------------- 
I personally wouldn't agree with that.

As described in 1551, it's nowhere really specified how the rules from REs
themselves and that what sed defines in addition work together, or
whichever wins in case of conflict.

E.g. sed also says that a delimiter preceded by \ would be taken literal,
where it's also not clear what:
snAAA[\n]nXXXn
should be taken for:
- \n being a literal n?
- \n being a newline?

(So that would actually be another point... which of those two "wins"?)


"So \n does not match newline when it appears within \\n for example."
=> IMO that ends up with the ambiguity I tried to describe in 1551. There
doesn't seem to be a general rule how the strings are parsed, and the test
sas just:
"The escape sequence '\n' shall match a <newline> embedded in the pattern
space"

It doesn't say however:
"… unless the preceding \ is itself quoted or the '\n' appears in a
context (like bracket expression) where the \ is already taken literally"


"The general rule for BREs is that backslash loses its special meaning in a
bracket expression"
=> yes, but the BRE section also specifies:
"The interpretation of an ordinary character preceded by an unescaped
<backslash> ( '\\' ) is undefined, except for:"

Which is already "overridden" by the rules in sed (i.e. that \n *does* have
a maning), so I don't think that one could argue that any "general rules
for BREs" would have clear precedence over that what sed says in addition. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2022-01-18 01:07 calestyo       New Issue                                    
2022-01-18 01:07 calestyo       Name                      => Christoph Anton
Mitterer
2022-01-18 01:07 calestyo       Section                   => Utilities, sed /
9.3.5 RE Bracket Expression
2022-01-18 01:07 calestyo       Page Number               => -               
2022-01-18 01:07 calestyo       Line Number               => -               
2022-01-18 09:41 geoffclare     Note Added: 0005621                          
2022-01-18 13:26 calestyo       Note Added: 0005622                          
======================================================================


  • [Issue 8 dra... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
      • Re:... Christoph Anton Mitterer via austin-group-l at The Open Group
        • ... Geoff Clare via austin-group-l at The Open Group
          • ... Christoph Anton Mitterer via austin-group-l at The Open Group

Reply via email to