Minutes of the 31st March 2022 Teleconference Austin-1210 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 1st April 2022 Attendees: Don Cragun, IEEE PASC OR Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR Geoff Clare, The Open Group Mark Ziegast, SHware Systems Dev. Eric Ackermann, HPI, University of Potsdam Eric Blake, Red Hat, The Open Group OR Apologies Andrew Josey, The Open Group Tom Thompson, IEEE * General news This was a call dedicated to general bugs. * Outstanding actions Bug 1533: struct tm: add tm_gmtoff (and tm_zone) field(s) OPEN https://austingroupbugs.net/bug_view_page.php?bug_id=1533 This was discussed in the February 3, 2022 teleconference. Leave it open until we get a more complete suggestion for the Desired Action. * Current Business Bug 1544: uudecode: standardise or at least reserve - as another special symbol for decoding to stdout https://austingroupbugs.net/view.php?id=1544 Open Left open, but status changed to "Resolution Proposed" Andrew still has the action to seek another contact at IBM. Bug 1546: BREs: reserve \? \+ and \| Accepted as Marked https://austingroupbugs.net/view.php?id=1546 There were two comments made against the last resolution. Updates now made to that note ... Change the definition of "escape sequence" to: An escape sequence is defined as the escape character ('\\'), when neither in a bracket expression nor itself escaped, followed by any single character. After the page 167 addition: The '?', '+', and '|' characters; it is implementation-defined whether "\?", "\+", and "\|" each match the literal character '?', '+', or '|', respectively, or behave as described for the ERE special characters '?', '+', and '|', respectively (see [xref to 9.4.3]). also add: Note: A future version of this standard may require "\?", "\+", and "\|" to behave as described for the ERE special characters '?', '+', and '|', respectively. See https://austingroupbugs.net/view.php?id=1546#c5755 for details Bug 1550: clarifications/ambiguities in the description of context addresses and their delimiters for sed OPEN https://austingroupbugs.net/view.php?id=1550 Geoff had completed his action to propose wording as suggested in bugnote 5756 Leave open for feedback. Bug 1551: sed: ambiguities in the how BREs/EREs are parsed/interpreted between delimiters (especially when these are special characters) OPEN https://austingroupbugs.net/view.php?id=1551 Geoff had completed his action to propose wording as suggested in bugnote 5756 Leave open for feedback. Bug 1555: -a/allexport spec should cover ${var=value} and ${var:=value} Accepted as Marked https://austingroupbugs.net/view.php?id=1555 This item is tagged for TC3-2008. An interpretation is required. Interpretation response: The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: The reference to XBD 4.23 implies that only certain types of assignment are affected by -a, but the later text referring to getopts and read contradicts that. Notes to the Editor (not part of this interpretation): On page 2409 line 77096 section 2.14 set, replace the description of the -a option with: Set the export attribute for all variable assignments. When this option is on, whenever a value is assigned to a variable in the current shell execution environment, the export attribute shall be set for the variable. This applies to all forms of assignment, including those made as a side-effect of variable expansions or arithmetic expansions, and those made as a result of the operation of the cd, getopts, or read utilities. Note: As discussed in Section 2.9.1, not all variable assignments happen in the current execution environment. When an assignment happens in a separate shell execution environment, the export attribute is still set for the variable, but that does not affect the current shell execution environment. Note to the editor: the -a description differs between the 2018 edition and Issue 8 draft 2.1. This new description replaces both. Bug 1556: clarify meaning of \n used in a bracket expression in a sed context address or s-command OPEN https://austingroupbugs.net/view.php?id=1556 Aim to close as a dup of 1550 when we resolve 1550. Bug 1557: Better wording to describe FD_CLOEXEC. OPEN https://austingroupbugs.net/view.php?id=1557 We will continue this next time Next Steps ---------- The next calls are on: Mon 2022-04-04 (gettext) Thu 2022-04-07 (general bugs) The calls are for 90 minutes Calls are anchored on US time. (8am Pacific) Apologies in advance: 2022-04-04, 2022-04-07 Andrew Josey Please check the calendar invites for dial in details. Bugs are at: https://austingroupbugs.net An etherpad is usually up for the meeting, with a URL using the date format as below: https://posix.rhansen.org/p/20xx-mm-dd (For write access this uses The Open Group single sign on, for those individuals with gitlab.opengroup.org accounts. Please contact Andrew if you need to be setup)