... (which consists of an RE, preceded and followed by a delimiter—usually a <slash>—as described in Regular Expressions in sed).

In a context address, a delimiter other than <slash> can be used by means of the construction ...

... preceded and followed by a delimiter, usually a <slash>).

In a context address, any character other than <backslash> or <newline> can be specified for use as the delimiter by means of the construction "\cREc", where c is the chosen delimiter character. The BRE and ERE syntax shall additionally support escaping occurrences of the delimiter within the RE with an unescaped <backslash> (except inside a bracket expression). If the character designated by c is not special in a BRE or ERE according to [xref to XBD 9.3] or [xref to XBD 9.4], respectively, the escape sequence <backslash>c shall be treated as that literal character; otherwise, it is unspecified whether the escape sequence <backslash>c is treated as the literal character or the special character. In either case, the escape sequence <backslash>c shall not terminate the RE. For example, the context address "\xabc\xdefx" is equivalent to "/abcxdef/".

The delimiter character that precedes and follows the RE shall not terminate the RE when it appears within a bracket expression. For example, the context address "/[/]/" is equivalent to "/\//".

Within the RE and the replacement, the RE delimiter itself can be used as a literal character if it is preceded by a <backslash>.

Within the RE and the replacement, the delimiter shall not terminate the RE or replacement if it is preceded by an unescaped <backslash> (that is not inside a bracket expression in the RE, where the delimiter does not terminate the RE anyway - see [xref to Regular Expressions in sed]). If the delimiter character is not special in a BRE or ERE according to [xref to XBD 9.3] or [xref to XBD 9.4], respectively, the escape sequence <backslash>delimiter shall be treated as that literal character in the RE; otherwise, it is unspecified whether the escape sequence <backslash>delimiter is treated as the literal character or the special character. Likewise, if the delimiter character is not <ampersand> ('&'), the escape sequence <backslash>delimiter shall be treated as that literal character in the replacement; if it is <ampersand>, it is unspecified whether the escape sequence <backslash>delimiter is treated as the literal character or the special character (see below).

... the delimiter itself can be used as a literal character if it is preceded by a <backslash>. If a <backslash> character is immediately followed by a <backslash> character in string1 or string2, the two <backslash> characters shall be counted as a single literal <backslash> character.

... the delimiter itself can be used as a literal character if it is preceded by an unescaped <backslash>. If a <backslash> character is escaped by an immediately preceding unescaped <backslash> character in string1 or string2, the two <backslash> characters shall be treated as a single literal <backslash> character.

Applications that use a special RE character as a delimiter (for example, '.' or '*') and need to use the delimiter as a literal character in the RE should put it inside a bracket expression, as implementations differ regarding whether escaping it with a <backslash> removes its special meaning.

Some historical sed implementations did not support escaping '(', ')', '{', and '}' when used as a BRE delimiter, as the sequences "\(" and so on were still treated as special, usually resulting in an error. This standard requires that these sequences are treated as the literal character. This is for consistency with extensions. For example, some implementations treat "\s" in a BRE as matching white-space characters, as an extension. This cannot have its special meaning when 's' is used as a BRE delimiter in order to ensure portability of sed commands that have 's' as a delimiter and escape it. If "\s" were allowed to keep its special meaning, then the potential for further extensions would mean portable applications would not be able to escape any delimiter character other than <slash>.

... preceded and followed by a delimiter, usually a <slash>).

In a context address, any character other than <backslash> or <newline> can be specified for use as the delimiter by means of the construction "\cREc", where c is the chosen delimiter character. The BRE and ERE syntax shall additionally support escaping occurrences of the delimiter within the RE by means of an escape sequence (see [xref to XBD 9.1]). If the character designated by c is not special in a BRE (if the -E option is not specified) or ERE (if -E is specified) according to [xref to XBD 9.3.3] or [xref to XBD 9.4.3], respectively, the escape sequence <backslash>c shall be treated as that literal character; otherwise, it is unspecified whether the escape sequence <backslash>c is treated as the literal character or the special character. In either case, the escape sequence <backslash>c shall not terminate the RE. The construction "\cREc" does not need to be used when the delimiter is a <slash>; for example, the context address "\xabc\xdefx" is equivalent to "/abcxdef/".

The delimiter character that precedes and follows the RE shall not terminate the RE when it appears within a bracket expression, and shall have its normal meaning in the bracket expression. For example, the context address "/[/]/" is equivalent to "/\//", and the command "s-[0-9]--g" is equivalent to "s/[0-9]//g".

Within the RE and the replacement, the RE delimiter itself can be used as a literal character if it is preceded by a <backslash>.

Within the RE and the replacement, the delimiter shall not terminate the RE or replacement if it is the second character of an escape sequence (see [xref to XBD 9.1]). If the delimiter character is not special in a BRE (if the -E option is not specified) or ERE (if -E is specified) according to [xref to XBD 9.3.3] or [xref to XBD 9.4.3], respectively, the escaped delimiter shall be treated as that literal character in the RE; otherwise, it is unspecified whether the escaped delimiter is treated as the literal character or the special character. Likewise, if the delimiter character is not <ampersand> ('&'), the escaped delimiter shall be treated as that literal character in the replacement; if it is <ampersand>, it is unspecified whether the escaped delimiter is treated as the literal character or the special character (see below).

... the delimiter itself can be used as a literal character if it is preceded by a <backslash>. If a <backslash> character is immediately followed by a <backslash> character in string1 or string2, the two <backslash> characters shall be counted as a single literal <backslash> character.

... the delimiter itself can be used as a literal character if it is preceded by an unescaped <backslash>. If a <backslash> character is escaped by an immediately preceding unescaped <backslash> character in string1 or string2, the two <backslash> characters shall be treated as a single literal <backslash> character.

Applications that use a special RE character as a delimiter (for example, '.' or '*') and need to use the delimiter as a literal character in the RE should put it inside a bracket expression, as implementations differ regarding whether escaping it with a <backslash> removes its special meaning. For example, the context address "\.[.][0-9]." is equivalent to "/\.[0-9]/"; however, with "\.\.[0-9]." it is unspecified which of "/\.[0-9]/" or "/.[0-9]/" is its equivalent form.

The characters <backslash> and <newline> cannot be used as RE delimiter characters (even in a context address using "\cREc"), as they can never be recognized as the ending delimiter:

• <backslash> does not work, because if it appears unescaped later in the RE, it either escapes the following character, which can then never be the ending delimiter, or it forms part of a bracket expression, inside which the ending delimiter for the RE cannot be located.


• <newline> does not work, because if not escaped, it terminates the command, meaning it cannot be the ending delimiter.

Some historical sed implementations did not support escaping '(', ')', '{', and '}' when used as a BRE delimiter, as the sequences "\(" and so on were still treated as special, usually resulting in an error. This standard requires that these sequences are treated as the literal character. This is for consistency with extensions. For example, some implementations treat "\s" in a BRE as matching white-space characters, as an extension. This cannot have its special meaning when 's' is used as a BRE delimiter in order to ensure portability of sed commands that have 's' as a delimiter and escape it. If "\s" were allowed to keep its special meaning, then the potential for further extensions would mean portable applications would not be able to escape any delimiter character other than <slash>.

or a context address (which consists of an RE, as described in [xref to Regular Expressions in sed], preceded and followed by a delimiter, usually a <slash>).

or a context address. A context address has either the form "/RE/" or "\cREc", where RE is a regular expression as described in [xref to Regular Expressions in sed], and c is any character other than <backslash> or <newline>. In a sed context address, the BRE and ERE syntax shall be extended to support escaping occurrences of the <slash> or c delimiter within the RE by means of an escape sequence (see [xref to XBD 9.1]). For the "\cREc" form, if the character designated by c is not listed as a special BRE character (if the -E option is not specified) or a special ERE character (if -E is specified) in [xref to XBD 9.3.3] or [xref to XBD 9.4.3], respectively, the escape sequence <backslash>c shall be treated as that literal character; otherwise, it is unspecified whether the escape sequence <backslash>c is treated as the literal character or the special character. In either case, the escape sequence <backslash>c shall not terminate the RE. For example, in the context address "/abc\/def/", the second <slash> stands for itself, so that the RE is "abc/def", and in "\xabc\xdefx", the second 'x' stands for itself, so that the RE is "abcxdef".

Both BREs and EREs shall also support the following additions

In sed, the BRE and ERE syntax shall be extended as follows

The delimiter character that precedes and follows the RE shall not terminate the RE when it appears within a bracket expression, and shall have its normal meaning in the bracket expression. For example, the context address "\%[%]%" is equivalent to "/[%]/", and the command "s-[0-9]--g" is equivalent to "s/[0-9]//g".

Within the RE and the replacement, the RE delimiter itself can be used as a literal character if it is preceded by a <backslash>.

Within the RE (as a sed extension to the BRE and ERE syntax) and the replacement, the delimiter shall not terminate the RE or replacement if it is the second character of an escape sequence (see [xref to XBD 9.1]). If the delimiter character is not listed as a special BRE character (if the -E option is not specified) or a special ERE character (if -E is specified) in [xref to XBD 9.3.3] or [xref to XBD 9.4.3], respectively, the escaped delimiter shall be treated as that literal character in the RE; otherwise, it is unspecified whether the escaped delimiter is treated as the literal character or the special character. Likewise, if the delimiter character is not <ampersand> ('&'), the escaped delimiter shall be treated as that literal character in the replacement; if it is <ampersand>, it is unspecified whether the escaped delimiter is treated as the literal character or the special character (see below).

A substitution shall be considered to have been performed even if the replacement string is identical to the string that it replaces. Any <backslash> used to alter the default meaning of a subsequent character shall be discarded from the RE or the replacement before evaluating the RE or using the replacement.

Any <backslash> used to alter the default meaning of a subsequent character shall be discarded from the resulting replacement string. A substitution shall be considered to have been performed even if the resulting replacement string is identical to the string that it replaces.

... the delimiter itself can be used as a literal character if it is preceded by a <backslash>. If a <backslash> character is immediately followed by a <backslash> character in string1 or string2, the two <backslash> characters shall be counted as a single literal <backslash> character.

... the delimiter itself can be used as a literal character if it is preceded by an unescaped <backslash>. If a <backslash> character is escaped by an immediately preceding unescaped <backslash> character in string1 or string2, the two <backslash> characters shall be treated as a single literal <backslash> character.

Applications that use a special RE character as a delimiter (for example, '.' or '*') and need to use the delimiter as a literal character in the RE should put it inside a bracket expression, as implementations differ regarding whether escaping it with a <backslash> removes its special meaning. For example, for the context address "/\.[0-9]/" to be written with '.' as delimiter, the form "\.[.][0-9]." needs to be used; "\.\.[0-9]." cannot be used portably for this purpose, as it is unspecified whether this would be equivalent to "/\.[0-9]/" or "/.[0-9]/". Portable applications cannot use a special RE character as a delimiter if that character needs to have its special meaning in the RE, as escaping it may remove its special meaning.

The characters <backslash> and <newline> cannot be used as RE delimiter characters, as they can never be recognized as the ending delimiter:

• <backslash> does not work, because if it appears unescaped later in the RE, it either escapes the following character, which can then never be the ending delimiter, or it is part of a bracket expression, inside which the ending delimiter for the RE cannot be located.


• <newline> does not work, because if not escaped, it terminates the command, meaning it cannot be the ending delimiter.

Some historical sed implementations did not support escaping '(', ')', '{', and '}' when used as a BRE delimiter, as the sequences "\(" and so on were still treated as special, usually resulting in an error. This standard requires that these sequences are treated as the literal character. This is for consistency with extensions. For example, some implementations treat "\s" in a BRE as matching white-space characters, as an extension. This cannot have its special meaning when 's' is used as a BRE delimiter in order to ensure portability of sed commands that have 's' as a delimiter and escape it. If "\s" were allowed to keep its special meaning, then the potential for further extensions would mean portable applications would not be able to escape any delimiter character other than <slash>.