Minutes of the 24th September 2020 Teleconference Austin-1066 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 26th September 2020 Attendees: Don Cragun, IEEE PASC OR Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Geoff Clare, The Open Group Andrew Josey, The Open Group Joerg Schilling, FOKUS Fraunhofer Eric Blake, Red Hat, The Open Group OR Richard Hansen Apologies: Eric Ackermann, Thu 2020-09-24 Mark Ziegast, SHware Systems Dev. Tom Thompson, IEEE * General news None. * 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 13th June 2019 and earlier) Bug 1254: "asynchronous list" description uses "command" instead of "AND-OR list" OPEN https://austingroupbugs.net/view.php?id=1254 Action: Joerg to investigate how his shell behaves. Bug 700 - Nick to raise this issue with the C committee Bug 713 - Nick to raise with the C committee. Bug 739 - Nick to raise with the C committee. * Current Business Bug 0000697: Adding of a getdirentries() function https://www.austingroupbugs.net/view.php?id=697 This has a separate etherpad page. https://posix.rhansen.org/p/bug697 Note that in this meeting we completed the Issue 8 draft 1 bugs and resumed our review of this bug. We will continue deliberations on this bug on Monday. Bug #1393: 'command' should not be treated as a declaration utility Accept as Marked https://www.austingroupbugs.net/view.php?id=1393 On page 2332 line 75618 section 2.14 export (APPLICATION USAGE), add a new paragraph: In shells that support extended assignment syntax, for example to allow an array to be populated with a single assignment, such extensions can typically only be used in assignments specified as arguments to export if the command word is literally export, and not if it is some other word that expands to export. For example: # Shells that support array assignment as an extension generally support this: export x=(1 2 3); echo ${x[0]} # outputs 1 # But generally do not support this: e=export; $e x=(1 2 3); echo ${x[0]} # syntax error On page 2332 line 75637 section 2.14 export (RATIONALE), add a new paragraph: Some implementations extend the shell's assignment syntax, for example to allow an array to be populated with a single assignment, and in order for such an extension to be usable in assignments specified as arguments to export these shells have export as a separate token in their grammar. This standard only permits an extension of this nature when the input to the shell would contain a syntax error according to the standard grammar. Note that although export can be a separate token in the shell's grammar, it cannot be a reserved word since export is a candidate for alias substitution whereas reserved words are not (see [xref to 2.3.1]). On page 2335 line 75721 section 2.14 readonly (APPLICATION USAGE), change: None. to: In shells that support extended assignment syntax, for example to allow an array to be populated with a single assignment, such extensions can typically only be used in assignments specified as arguments to readonly if the command word is literally readonly, and not if it is some other word that expands to readonly. For example: # Shells that support array assignment as an extension generally support this: readonly x=(1 2 3); echo ${x[0]} # outputs 1 # But generally do not support this: r=readonly; $r x=(1 2 3); echo ${x[0]} # syntax error On page 2335 line 75739 section 2.14 readonly (RATIONALE), add a new paragraph: Some implementations extend the shell's assignment syntax, for example to allow an array to be populated with a single assignment, and in order for such an extension to be usable in assignments specified as arguments to readonly these shells have readonly as a separate token in their grammar. This standard only permits an extension of this nature when the input to the shell would contain a syntax error according to the standard grammar. Note that although readonly can be a separate token in the shell's grammar, it cannot be a reserved word since readonly is a candidate for alias substitution whereas reserved words are not (see [xref to 2.3.1]). On page 2514 line 82700 section command (RATIONALE), change: ... or that prevents function lookup on b or c. to: ... or that prevents function lookup on b or c. However, some implementations extend the shell's assignment syntax, for example to allow an array to be populated with a single assignment, and in order for such an extension to be usable in assignments specified as arguments to export and readonly these shells have those utility names as separate tokens in their grammar. When command is used to execute these utilities it also needs to be a separate token in the grammar so that the same extended assignment syntax can still be recognized in this case. This standard only permits an extension of this nature when the input to the shell would contain a syntax error according to the standard grammar, and therefore it cannot affect how '|' and ';' are parsed in the example above. Note that although command can be a separate token in the shell's grammar, it cannot be a reserved word since command is a candidate for alias substitution whereas reserved words are not (see [xref to 2.3.1]). Bug #1394: Another way the getenv() return string is modifiable Accept https://www.austingroupbugs.net/view.php?id=1394 Bug #1398: New API mkostemp() needs redirect page Accept https://www.austingroupbugs.net/view.php?id=1398 Gettext draft. We will return to this on a future call. The gettext draft in the etherpad is at https://posix.rhansen.org/p/gettext_draft https://posix.rhansen.org/p/gettext_split Next Steps ---------- The next calls are on: September 28th 2020 (Monday) This call will be for 60 minutes. October 1st 2020 (Thursday) This call will be for 90 minutes. Calls are anchored on US time. (8am Pacific) Apologies in advance: Andrew Josey, Thu 2020-09-28 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)