Stephane Chazelas <[email protected]> wrote, on 03 May 2018: > > 2018-05-03 17:38:16 +0100, Geoff Clare: > [...] > > > Does that mean that: > > > > > > awk '/[\]]/' > > > > > > is to match on "\]" and not on "]" (like for grep -E '[\]]')? > > > > As things stand, since "\]" is not in the table above, it is covered > > by the "\c" catchall (last row of the table) which says the behaviour > > is undefined. > [...] > > Thanks. Got you. > > But now you know what my next question will be: should > > awk '/[\^x]/' > > match 1) on \, ^ or x > 2) or ^ or x > 3) or any character but x > > Again, except for busybox awk and Solaris /usr/xpg4/bin/awk > (which do 1), all do 2.
Good catch - looks like we overlooked \^ in bracket expressions. The table addition has \^ because ^ is an anchor (outside brackets), but because it doesn't specify any difference between inside and outside brackets, this means the current resolution requires 1 above. > 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, 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. -- Geoff Clare <[email protected]> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
