Minutes of the 18th July 2022 Teleconference Austin-1240 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 20th July 2022 Attendees: Don Cragun, IEEE PASC OR Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR Andrew Josey, The Open Group Geoff Clare, The Open Group Eric Blake, Red Hat, The Open Group OR Mark Ziegast, SHware Systems Dev. Tom Thompson, IEEE Apologies Eric Ackermann, HPI, University of Potsdam * General news This was a call dedicated to general bugs. The annual reports to SC22 and others have been submitted and also posted to the document register. * Current Business Bug 1122: POSIX should include gettext() and friends OPEN and https://posix.rhansen.org/p/gettext_draft Also https://austingroupbugs.net/file_download.php?file_id=64&type=bug Geoff's addition to XRAT appendix E was noted. A new PDF will be needed, but we will wait for more comments first. To be discussed again when more comments are raised. Bug 1560: clarify wording of command substitution https://austingroupbugs.net/view.php?id=1560 Leave this and related bugs 1561 and 1564 open awaiting reviews/discussion. Bug 1273: glob()'s GLOB_ERR/errfunc and non-directory files OPEN https://austingroupbugs.net/view.php?id=1273 We will leave this open awaiting feedback. Bug 1219: snprintf reequirement to fail when n > INT_MAX conflicts with C Accepted as Marked https://austingroupbugs.net/view.php?id=1219 This item is tagged for TC3-2008 Delete lines 30917-30918 in D2.1 (page 904). Change page 990 line 33924 in D2.1 from: The value of n is greater than {INT_MAX}. to: The number of wide characters requested to be written was n or more. Bug 1193: Brace expansion and {var}>file redirects in the shell Accepted as Marked https://austingroupbugs.net/view.php?id=1193 This item is tagged for TC3-2008 On page 2346 line 74699 section 2.2 add: { , } to the list of characters that might need to be quoted and add a small-font note after the list: Note: a future version of this standard may extend the conditions under which these characters are special. Therefore applications should quote them whenever they are intended to represent themselves. This does not apply to ('-') since it is in the portable filename character set. (Note to the editor: this last sentence assumes that '-' is added by 0001191.) On page 2353 line 74994 section 2.6 change: ... expand to a single field. It is only field splitting or pathname expansion that can create multiple fields from a single word. The single exception to this rule is the expansion of the special parameter '@' within double-quotes, as described in [xref to 2.5.2]. to: ... shall expand to a single field, except as described below. The shell shall create multiple fields or no fields from a single word only as a result of field splitting, pathname expansion, or the following cases: Parameter expansion of the special parameters '@' and '*', as described in [xref to 2.5.2], can create multiple fields or no fields from a single word. When the expansion occurs in a context where field splitting will be performed, a word that contains all of the following somewhere within it, before any expansions are applied, in the order specified: an unquoted ('{') that is not immediately preceded by an unquoted ('$'), one or more unquoted (',') characters or a sequence that consists of two adjacent ('.') characters surrounded by other characters (which can also be characters), and an unquoted ('}') may be subject to an additional implementation-defined form of expansion that can create multiple fields from a single word. This expansion, if supported, shall be applied before all the other word expansions are applied. The other expansions shall then be applied to each field that results from this expansion. On page 2360 line 75303 section 2.7 add a new paragraph: The shell may support an additional format used for redirection: {location}redir-op word where location is non-empty and indicates a location where an integer value can be stored, such as the name of a shell variable. If this format is supported its behavior is implementation-defined. On Page 2375 line 75883 section 2.10.1 change: 2. [...] shall be returned. 3. Otherwise, the token identifier TOKEN results. to: 2. [...] shall result. 3. If the string contains at least three characters, begins with a ('{') and ends with a ('}'), and the delimiter character is one of '<' or '>', the token identifier IO_LOCATION may result; if the result is not IO_LOCATION, the token identifier TOKEN shall result. 4. Otherwise, the token identifier TOKEN shall result. On Page 2377 line 75968 section 2.10.2 add: %token IO_LOCATION On Page 2380 line 76116 section 2.10.2 change: io_redirect : io_file | IO_NUMBER io_file | io_here | IO_NUMBER io_here ; to: io_redirect : io_file | IO_NUMBER io_file | IO_LOCATION io_file /* Optionally supported */ | io_here | IO_NUMBER io_here | IO_LOCATION io_here /* Optionally supported */ ; Cross-volume changes to XRAT... On page 3718 line 127432 section C.2.2 change: There is no additional rationale provided for this section. to: Although this section contains a note indicating that a future version of this standard may extend the conditions under which some characters are special, there are no plans to do so. The note is there to encourage application writers to future-proof their shell code. In some cases existing widespread use of the characters unquoted would preclude them being given a special meaning in those use cases. For example, commas are in widespread use in filenames (notably by RCS and CVS) and it is common to pass the token "{}" as an argument to find and xargs unquoted. On page 3727 line 127859 section C.2.6 add a new first paragraph: Some shells implement brace expansion which expands, for example, file{A,B,C}.c into the fields fileA.c, fileB.c and fileC.c or file{1..3}.c into the fields file1.c, file2.c and file3.c. This form of expansion is allowed but not required by this standard, but if supported must be performed before all of the standard word expansions. A variant which some shells implement whereby brace expansion is performed following field splitting was considered by the standard developers and rejected because it causes surprising behavior if the results of parameter expansion and command substitution happen to produce a valid brace expansion. For example, if the shell variable patt contains an arbitrary pathname glob pattern applications cannot rely on some_command -- $patt passing a list of pathnames that match the pattern to some_command. Note that quoting the braces or commas prevents this form of expansion, but quoting the periods need not prevent it. On page 3735 line 128185 section C.2.7 add a new paragraph: The limitation to 9 file descriptors is overcome in some shells via a form of redirection whereby a shell variable stores the file descriptor number. For example: exec {fdvar}> foo opens the file foo on a file descriptor greater than 9 and stores the file descriptor number in shell variable fdvar. (This can later be closed using exec {fdvar}>&-.) This form of redirection is allowed but not required by this standard. On page 3746 line 128634 section C.2.10 add a new paragraph: The optional redirection syntax: {name}redir-op word (see [xref to XCU 2.7]) is accommodated in the grammar rules by the optional IO_LOCATION token identifier and two correspondingly optional elements in io_redirect. Without these, the grammar would not permit this form of redirection because it would require that, for example, echo {var}> foo is parsed such that {var} is a WORD to be expanded and passed to echo. The grammar does not restrict the location given between the '{' and '}' in these forms (other than requiring it to be non-empty) since shells may parse an invalid location as part of an io_redirect and later treat the invalid location as an error. Bug 1165: What is the working group's plan for stateful polling (e.g., kqueue, epoll), event loops (libuv) and coroutines (C++2a)? Rejected https://austingroupbugs.net/view.php?id=1165 Since no full proposal has been submitted, this bug is rejected. If a full proposal is available at a later date, please file a new bug with the details. Bug 1068: Binding to a system-assigned port. OPEN https://austingroupbugs.net/view.php?id=1068 We will pick up on this item next time. Next Steps ---------- The next calls are on: Thu 2022-07-21 (general bugs) Mon 2022-07-25 (general bugs) gettext is complete, but may be discussed again if comments are added The calls are for 90 minutes Apologies in advance 2022-07-25 Andrew Josey Calls are anchored on US time. (8am Pacific) 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)