| Newsgroups |
gmane.editors.sed.user |
| Message-ID |
<[email protected]> |
On 2018-05-06 19:53, Stephane Chazelas [email protected]
[sed-users] wrote:
> 2018-05-06 07:31:30 -0500, Tim Chase [email protected] [sed-users]:
> > This is actually POSIX which requires a newline or semicolon
> > before a close-brace:
> >
> > "The <right-brace> shall be preceded by a <newline> or <semicolon>
> > (before any optional <blank> characters preceding the
> > <right-brace>)."
> >
> > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html#tag_20_116_13_03
>
> GNU sed is not violating POSIX here, a script that relies on the
> specific behaviour of GNU sed (of treating it as if there was
> a ; before the }) or for that matters on the BSD behaviour (of
> failing with an error, though it would be very unusual for a
> script to rely on a utility returning with an error) would be
> the ones being non-conformant.
The violation is that the spec says that a <newline> or <semicolon>
MUST precede a closing brace. GNU sed doesn't adhere to this part of
the spec or enforce it. That means that people can end up writing
sed scripts that they think are POSIX compliant, but aren't; and when
those non-compliant scripts are run in a POSIX-compliant version of
sed, they break.
> POSIX doesn't specify the behaviour for {s/x/y/} so either
> failing with an error, or the GNU behaviour (or any other
> behaviour) are valid behaviours.
POSIX does define correctness though: it SHALL be preceded by a
semicolon or newline. From RFC2119
"MUST: This word, or the terms "REQUIRED" or "SHALL", mean that
the definition is an absolute requirement of the specification."
(*) https://www.ietf.org/rfc/rfc2119.txt
GNU sed does not treat a semicolon/newline-before-close-brace as
required, despite the spec requiring it.
> The GNU behaviour is a more useful one. The only problem with it is
> that it doesn't help you realise that your script is not portable.
Agreed.
> POSIXLY_CORRECT is to have tools align with POSIX when they
> don't by default.
Which is exactly what GNU sed is doing here, being misaligned with
POSIX so the best outcome would be for GNU sed to respect
POSIXLY_CORRECT in this case, as it does with your [\t] example:
> For instance, sed 's/[\t]//' is required to remove every
> instance of backslash and t characters per POSIX, which GNU sed
> doesn't do by default (and in that would not be compliant). GNU
> sed only does that under POSIXLY_CORRECT (otherwise it removes
> TAB characters instead).
Also helpful to know.
-tim