Re: [1003.1(2016)/Issue7+TC2 0001105]: problems with backslashes in awk strings and EREs

2018-05-09 Thread Stephane Chazelas
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

Re: [1003.1(2016)/Issue7+TC2 0001105]: problems with backslashes in awk strings and EREs

2018-05-09 Thread Geoff Clare
Robert Elz wrote, on 09 May 2018: > > | In the lexical token ERE when not inside a bracket expression, > | the sequence shall represent itself. Otherwise undefined. > > Does it need to be undefined, or can it just be unspecified? The existing text says undefined, so we used it in the

Re: [1003.1(2016)/Issue7+TC2 0001105]: problems with backslashes in awk strings and EREs

2018-05-09 Thread Geoff Clare
Stephane Chazelas wrote, on 09 May 2018: > > \ treated specially > inside bracket expressions in practice is more common than the > behaviour POSIX specifies where it's not treated specially. > > I'm fine that POSIX requires []xyz] to match on ] and [xy-] on - > and that it's the only portable

Re: [1003.1(2016)/Issue7+TC2 0001105]: problems with backslashes in awk strings and EREs

2018-05-09 Thread Stephane CHAZELAS
2018-05-03 15:54:58 +, Austin Group Bug Tracker: [...] > On page 2492 line 80143 section awk, add to the Description > column:If the digits produce a value greater than octal 377, > the behavior is undefined. [...] A slightly related question. For printf "%c", POSIX says: }  7. For the c conv

[1003.1(2013)/Issue7+TC1 0000901]: reserve _POSIX* shell option namespace for future use

2018-05-09 Thread Austin Group Bug Tracker
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=901 == Reported By:rhansen Assigned To: ===

[1003.1(2013)/Issue7+TC1 0000901]: reserve _POSIX* shell option namespace for future use

2018-05-09 Thread Austin Group Bug Tracker
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=901 == Reported By:rhansen Assigned To: ===

[1003.1(2013)/Issue7+TC1 0001071]: Name space reservation should move to XBD

2018-05-09 Thread Austin Group Bug Tracker
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1071 == Reported By:nick Assigned To: =

Re: [1003.1(2016)/Issue7+TC2 0001105]: problems with backslashes in awk strings and EREs

2018-05-09 Thread Stephane Chazelas
2018-05-04 16:10:25 +0100, Geoff Clare: [...] > It was a deliberate choice made by the original POSIX.2 developers. > See XRAT A.9.3.5: > > Current practice in awk and lex is to accept escape sequences in > bracket expressions as per XBD Table 5-1 (on page 121), while the > normal ERE

Re: [1003.1(2016)/Issue7+TC2 0001105]: problems with backslashes in awk strings and EREs

2018-05-09 Thread Robert Elz
Date:Wed, 9 May 2018 09:18:37 +0100 From:Geoff Clare Message-ID: <20180509081837.GA24339@lt2.masqnet> | In the lexical token ERE when not inside a bracket expression, | the sequence shall represent itself. Otherwise undefined. Does it need to be undefined

Re: [1003.1(2016)/Issue7+TC2 0001105]: problems with backslashes in awk strings and EREs

2018-05-09 Thread Geoff Clare
Geoff Clare wrote, on 04 May 2018: > > Stephane Chazelas wrote, on 04 May 2018: > > > > That would not be enough to match the current reality, I'd say > > \ (\n, \ooo, \b...) at least should > > be undefined inside bracket expressions. > > I'd be okay with that. Nobody has objected to this solu