2018-05-09 15:07:24 +0100, Geoff Clare:
[...]
> > I don't see the point of "requiring" that $0 ~ "\\f" match a FF.
>
> It's a consequence of the way literal strings are turned into EREs.
> When this happens, backslashes are interpreted twice at the lexical
> level, as stated clearly in the current standard (in the paragraph
> after Table 4-2).
[...]
OK, I think I see what you mean. So we have
"string" undergoes the STRING-type of expansions where:
\n -> LF
\\ -> \
\[ -> undefined
\" -> "
\134 -> \
\136 -> ^ (on ASCII systems)
and when that is passed to ~, a ERE-type of expansions is done
as a second round where:
\\ -> \\
\134 -> \
\n ->
\[ -> \[
\^ -> \^ (except in bracket expressions, where it's undefined?)
\/ -> / (except in bracket expressions?)
And the resulting string is passed to the ERE engine and
interpreted the same way as if passed to grep -E.
I don't think the text makes it very clear though that it's two
different types of expansions that are being made here upon
x =~ "re"
>
> > Many implementations don't do it and I don't imagine them
> > changing any time soon (several of them still don't support
> > {x,y} RE intervals).
>
> It has been reported to Oracle as a Solaris bug, so that one at
> least is expected to change.
>
> Any that don't support {x,y} are hopelessly non-conforming (it's been
> a POSIX requirement for 26 years!) which means we shouldn't give them
> much, if any, weight when considering other awk conformance matters.
I'd agree with that. Note that we're talking of Solaris nawk,
bwk's awk, mawk, FreeBSD awk at least (gawk changed recently;
before that, you had to run it under POSIXLY_CORRECT to get the
braces or pass a --re-interval option IIRC).
[...]
> If you don't like some of our proposed changes, you are free to
> suggest alternative detailed wording changes. However, I can't
> promise that they will be considered, especially if they take a
> different direction than the one we reached consensus on in the calls.
[...]
Note that I'm a *user* of Unix-like systems (I'm not the
maintainer nor do I contribute to any awk implementation). I
raised the issue because I felt there was an issue in the
standard in that it didn't reflect existing practice and gave
wrong expectations to user like me wanting to write portable
code.
I do think the proposed change is an improvement, but I'm not
optimistic that it will be implemented widely, so we may very
well be in the same situation where POSIX doesn't reflect the
reality. Which is why I was rather proposing a wording that
reflects the behaviour of current implementations even if it
slightly limits what users can do.
--
Stephane
