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 17:12 UTC
====================================================================== 
Summary:                    clarify meaning of \n used in a bracket expression
in a sed context address or s-command
====================================================================== 

---------------------------------------------------------------------- 
 (0005624) calestyo (reporter) - 2022-01-18 17:12
 https://austingroupbugs.net/view.php?id=1556#c5624 
---------------------------------------------------------------------- 
Well one can read it like that, but it feels that requires quite some
imagination an is not really obvious.


Plus that concept doesn't seem to be used throughout the standard:

In most places \ is rather regarded as "special character", e.g. \1 or \2.

Or you have phrases like "The interpretation of an ordinary character
preceded by an unescaped <backslash> ( '\\' ) is undefined, except for:"
=> If the standard would always use the semantics as you imply, there
should be no need here to mention that the backslash needs to be unescaped,
because it would be "clear" that it needs to be so, in order to have an
escaping meaning on the following.

Or "Within the BRE and the replacement, the BRE delimiter itself can be
used as a literal character if it is preceded by a <backslash>."
=> there it should (probably?) also mean *the escape sqeuence* \ delimiter
... but id doesn't say that... it merely says delimiter preceded by
backslash.



>in [\n] there is no escape sequence at all,
>as there's no escape character there.

=> Cannot really agree, that this is so obviously clear.
If I just follow what's written in  9. Regular Expressions, then yes, it
would be clear.

But with what's written in "Regular Expressions in sed", I don't think it's
really 100% clear what's meant.
In the first bullet point here:
»In a context address, the construction "\cBREc", where c is any character
other than <backslash> or <newline>, shall be identical to "/BRE/". If the
character designated by c appears following a <backslash>, then it shall be
considered to be that literal character, which shall not terminate the BRE.
For example, in the context address "\xabc\xdefx", the second x stands for
itself, so that the BRE is "abcxdef".«

It doesn't use any such meaning as "escape sequence" in the sense that it
only applies when it really is one.

In the 2nd bullet point there:
»The escape sequence '\n' shall match a <newline> embedded in the pattern
space. A literal <newline> shall not be used in the BRE of a context
address or in the substitute function.«

it does... but it's in principle still open, whether that rule is applied
before or (from left-to-right) at the same time with the normal rules for
REs.


Similar to above, what would the follwoing be:
snAAA\nnXXXn

There is no [...], so it would be a perfect escape sequence in your sense.
But it also fits the "If the character designated by c appears following a
<backslash>, then it shall be considered to be that literal character,
which shall not terminate the BRE." 

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                          
2022-01-18 16:30 kre            Note Added: 0005623                          
2022-01-18 17:12 calestyo       Note Added: 0005624                          
======================================================================


  • [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
            • ... Geoff Clare via austin-group-l at The Open Group
        • ... Eric Blake via austin-group-l at The Open Group

Reply via email to