2018-05-04 09:30:56 +0100, Geoff Clare: [...] > > That's the point: we should allow \ to be an escaping operator > > inside brackets. In awk and anything else. Technically, that > > means a portable application has to double the \ inside > > brackets. > > The point of awk's extra level of \ interpretation is to allow the > use of \t for TAB, etc. And that's the only reason to use it inside > a bracket expression, since the XBD ERE rules say \ is not special > in a bracket expression,
It says that, but it doesn't match the reality of current awk implementations where \ is special within brackets (and also in many shell wildcards and in some sed, ex, vi implementations, and in most REs outside of POSIX). It's not only about ^. /[\*]/ fails to match to match backslash as well for instance (in all but busybox and Solaris /usr/xpg4/bin/awk). > This alone is enough to mean portable applications have to use \\ > inside brackets to include \ in the list of characters to match. > So I think we should just make \^ inside a bracket expression > undefined. That would not be enough to match the current reality, I'd say \<anything-but-the-C-escapes> (\n, \ooo, \b...) at least should be undefined inside bracket expressions. Note that there's a similar problem with sed where using \n inside bracket expressions is not portable (and IIRC unclear in the spec). Does the change address the differences in behaviour for PATTERN='\f' awk '$0 ~ $ENVIRON["PATTERN"]' or awk '$0 ~ "\\f"' that is where the \<C-escape> is not inside a literal STRING (where \f is expanded to a FF by awk) or ERE token (where POSIX says it's to be expanded to a FF before calling the regexp engine but is not the case in all implementations, where some have the regexp engine understand the \f)? You said earlier that, echo b | awk '/[a\55c]/' is required to match (on ASCII-based systems), but that's not the case with several implementations (like nawk on Solaris, bwk's awk, mawk, FreeBSD awk...). Should those be considered non-compliant? -- Stephane
