Minutes of the 17th May 2018 Teleconference Austin-868 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 18th May 2018 Attendees: Joerg Schilling, FOKUS Fraunhofer Geoff Clare, The Open Group Don Cragun, IEEE PASC OR David Clissold, IBM Andrew Josey, The Open Group Eric Blake, Red Hat Mark Ziegast, SHware Systems Dev. Apologies: Richard Hansen, Google Martin Rehak, Oracle, The Open Group OR Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR * General news No news * Outstanding actions ( Please note that this section has been flushed to shorten the minutes - to locate the previous set of outstanding actions, look to the minutes from 9 March 2018 and earlier) * Current Business Bug 1077: Recommend support for wide-character regcomp and regexec and/or specify multi-byte behavior OPEN http://austingroupbugs.net/bug_view_page.php?bug_id=1077 Andrew has completed the action to ping his Apple contact and is awaiting a reply. Bug 1105: problems with backslashes in awk strings and EREs Accepted as marked. http://austingroupbugs.net/view.php?id=1105 An interpretation is required. This item is tagged for TC3-2008. Interpretation response: The standard states the requirements for handling of in awk, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: The standard does not match historical and current practice. Notes to the Editor (not part of this interpretation): On page 2491 line 80125 section awk change: The awk utility shall make use of the extended regular expression notation (see [xref to XBD 9.4]) except that it shall allow the use of C-language conventions for escaping special characters within the EREs, as specified in the table in XBD Chapter 5 (on page 121) ('\\', '\a', '\b', '\f', '\n', '\r', '\t', '\v') and the following table; these escape sequences shall be recognized both inside and outside bracket expressions. to: The awk utility shall make use of the extended regular expression notation (see [xref to XBD 9.4]) except that it shall allow the use of C-language conventions for escaping special characters within the EREs, as specified in the table in XBD Chapter 5 (on page 121) for '\a', '\b', '\f', '\n', '\r', '\t', '\v' and in the following table for other sequences; these escape sequences shall be recognized both inside and outside bracket expressions. On page 2492 line 80136 section awk, change the Meaning column from: character to: In the lexical token STRING, character. Otherwise undefined. On page 2492 line 80137 section awk, change the Meaning column from: character to: In the lexical token ERE, character. Otherwise undefined. 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. On page 2492 line 80144 section awk, add two new rows to the table: \., \[, \(, \*, \+,| A character followed | In the lexical token ERE when \?, \{, \|, \^, \$ | by a character that has a special | not inside a bracket expression, | meaning in EREs (see [xref to XBD | the sequence shall represent | 9.4.3]), other than . | itself. Otherwise undefined. -------------------+-----------------------------------+--------------------------------- \\ | Two characters. | In the lexical token ERE, | | the sequence shall represent | | itself. In the lexical token | | STRING, it shall | | represent a single . (Note that the extra blank line is a Mantis artifact.) On page 2492 line 80161 section awk, change: Note that these same escape conventions shall also be applied ... to: Note that these escape conventions shall also be applied ... On page 2508 line 80877 section awk add a new first paragraph to APPLICATION USAGE: Since has a special meaning both in the option-argument to the -v option and in the assignment operand, applications that need to pass strings to awk without special interpretation of should not use these methods but should instead make use of the ARGV or ENVIRON array. Bug 1100: Rewrite of Section 2.10 Shell Grammar, of the Shell Standard, to fix previous reports, fix new issues, and improve presentation. Rejected http://austingroupbugs.net/view.php?id=1100 We believe that some of the changes suggested in this bug report reflect a misunderstanding of the grammar as it is presented in the standard rather than problems in the grammar itself. With no rationale for the changes that are being made, no indication of what is intended to be fixed by the changes that have been made, and no definitions for new terms that have been added to the grammar and the description of the grammar, we are unable to determine which, if any, of the suggested changes should be made. We believe that there may be discrepancies between the grammar as it currently appears in the standard and the shell language described by the standard, but are unable to determine which, if any, of the changes suggested in this bug report address those problems. We are going to reject this bug report, but would be happy to have the submitter provide another bug report with a list of defects that need to be addressed and a set of changes to meet those defects (with each change identifying the defect it addresses). We would also like to see addtitions to the definitions section for newly defined terms (e.g., "important" characters) and changes to the rationale in XRAT C.2.10 explaining how the grammar is being changed to reflect differences between what the standard has intended to require and what the grammar currently does require. When describing problems in the grammar, giving an example of a shell construct that is not accepted by the grammar when it should be or that is accepted by the grammar when it should not be would be a big help in understanding the issues that are being addressed by proposed changes. Note that existing shells are allowed to support extensions to constructs required by the POSIX shell grammar. Therefore, there is no requirement that all existing shell constructs need to be recognized by the grammar. Bug 1106: *rand48(): Should this use uint16_t instead of unsigned short? OPEN http://austingroupbugs.net/view.php?id=1106 This will be continued next time. Next Steps ---------- The next call is on May 24th, 2018 (a Thursday) Andrew to bring up the bridge. Calls are anchored on US time. (8am Pacific) This call will be for the regular 90 minutes. http://austingroupbugs.net An etherpad is usually up for the meeting, with a URL using the date format as below: https://posix.rhansen.org/p/201x-mm-dd username=posix password=2115756#