Robert Elz wrote, on 05 Apr 2022:
>
> | Okay, I'll see what I can do. It may make sense to use the new
> | definition of "escape sequence" from bug 1546.
>
> | It won't be possible in the y command, as that doesn't use an RE (so
> | would need its own definition of "escape character").
>
> I wasn't paying attention to just where any of this was to be placed in
> the final doc, but couldn't the definition of "escape sequence" (and those
> related to it) be somewhere generic?
The new definition in bug 1546 is specific to regular expressions
(since it talks about the backslash not being in a bracket expression),
so it's going in XBD 9.1 with the other "Regular Expression Definitions".
> | What matters is that the delimiter can only be escaped with an
> | _unescaped_ backslash, and that it doesn't end the RE when it is in a
> | bracket expression. I believe my proposal makes both of those things
> | clear.
>
> I suspect that the point was more related to when 2-pass parsing is used,
> and an escaped delimiter is seen, does the second pass still see the escaped
> delimiter, or is it now unescaped. I'm no sed expert (I use it a lot,
> but have never really looked into an implementation, and don't push the
> wacky boundary cases in my uses) - but I believe this is to be explicitly
> unspecified (that is, implementations can do either, and applications must
> not depend upon which is done).
Yes that issue, too, is covered by the proposed text. I believe it
says everything that needs to be said about behaviour that could be
affected by the number of passes, and nothing needs to be said about
the actual number of passes.
> | > => And perhaps something like "should put it inside a bracket
> | > expression __with not other characters__" to make clear, that one
> | > cannot re-use one e.g. 'sX\X[0-9]XfooX' can NOT be written as
> | > 'sX[X0-9]XfooX' but only as 'sX[X][0-9]XfooX'.
> |
> | Incorrect, sX[X0-9]XfooX is required to "work"
>
> I think the point there was that it doesn't mean the same thing, in that
> one a single char is being substituted, in the others, it is a 2 char
> sequence,
> the delimiter, followed by a digit, not either the delimiter or a digit.
Okay, it seems there's a mismatch between the stated problem and the
proposed solution. The proposed solution implies that the delimiter
character can't be put in a bracket expression with other characters,
even if that's the behaviour the user wants. Rather than try to come
up with new descriptive words, I think it could be illustrated with
an example, e.g. adding:
For example, the context address "\.[.][0-9]." is equivalent
to "/\.[0-9]/".
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
