Re: sed POSIX compatibility regarding '|' in regular expressions

[Bruno Haible]

Eric Blake wrote:
> > Bug #1: The --posix option fails to turn off this GNU extension.
> 
> I disagree.  The fact that \| is undefined in POSIX means that sed is free
> to assign it any meaning it wants, including as the alternation operator,
> and this does not count as an extension since POSIX left it undefined.  A
> POSIX portable application will never pass such a sequence to sed.

True. But the description of the --posix option explains that it turns off
_all_ non-POSIX behaviour:

   `--posix'
     GNU `sed' includes several extensions to POSIX sed.  In order to
     simplify writing portable scripts, this option disables all the
     extensions that this manual documents, including additional
     commands.  ... If you want to disable
     only [the extensions that conflict with POSIX], you can set the
     `POSIXLY_CORRECT' variable to a non-empty value.

And the same manual documents:

   `REGEXP1\|REGEXP2'
     Matches either REGEXP1 or REGEXP2.  Use parentheses to use complex
     alternative regular expressions.  The matching process tries each
     alternative in turn, from left to right, and the first one that
     succeeds is used.  It is a GNU extension.
                        ======================

> I would prefer the goal of 'sed --posix' to be disabling only GNU extensions
> that conflict with POSIX, rather than crippling sane semantics for
> sequences intentionally left undefined by POSIX.

The purpose that you desire is available through the POSIXLY_CORRECT=1
environment setting. I'm talking about --posix; this is a different thing.

I, for one, wish I had noted earlier that some sed expressions that I was
using were not portable according to POSIX. --posix appears to be made for
this purpose. Like -ansi -pedantic for gcc.

Bruno