All
Enclosed are the minutes from the Monday meeting
regards
Andrew
-------------
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 <hyphen-minus> ('-') 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 <left-curly-bracket> ('{') that is not
immediately preceded by an unquoted <dollar-sign> ('$'),
one or more unquoted <comma> (',') characters or a
sequence that consists of two adjacent <period> ('.')
characters surrounded by other characters (which can
also be <period> characters), and
an unquoted <right-curly-bracket> ('}')
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 <left-curly-bracket> ('{') and ends with a <right-curly-bracket>
('}'), 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,
<tt>file{A,B,C}.c</tt> into the fields <tt>fileA.c</tt>,
<tt>fileB.c</tt> and <tt>fileC.c</tt> or <tt>file{1..3}.c</tt>
into the fields <tt>file1.c</tt>, <tt>file2.c</tt> and
<tt>file3.c</tt>. 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 <tt>patt</tt> contains an arbitrary pathname
glob pattern applications cannot rely on <tt>some_command --
$patt</tt> passing a list of pathnames that match the pattern
to <tt>some_command</tt>. 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 <tt>foo</tt> on a file descriptor greater than
9 and stores the file descriptor number in shell variable
<tt>fdvar</tt>. (This can later be closed using <tt>exec
{fdvar}>&-</tt>.) 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 <tt>io_redirect</tt>. Without these, the
grammar would not permit this form of redirection because it
would require that, for example, <tt>echo {var}> foo</tt> is
parsed such that <tt>{var}</tt> 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 <tt>io_redirect</tt> 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)
--------
Andrew Josey The Open Group
Austin Group Chair
Email: a.jo...@opengroup.org
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England
To learn how we maintain your privacy, please review The Open Group Privacy
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub&listid=2481
