All
These are the minutes from this weeks teleconference
regards
Andrew
------
Minutes of the 1st March 2018 Teleconference Austin-857 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 3rd March 2018
Attendees:
Don Cragun, IEEE PASC OR
Joerg Schilling, FOKUS Fraunhofer
David Clissold, IBM (from 1 hour mark)
Geoff Clare, The Open Group
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Richard Hansen, Google
Eric Blake, Red Hat
Apologies:
Andrew Josey
Martin Rehak
Mark Ziegast
* 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 28 Jan 2016)
Bug 0000249: Add standard support for $'...' in shell Reopened
http://austingroupbugs.net/bug_view_page.php?bug_id=249
We will return to bug 249 on a future call.
Bug 0000953: Alias expansion is under-specified Was Accepted as Marked
http://austingroupbugs.net/view.php?id=953
Richard has an action to propose new wording to discuss in a future telecon.
* Current Business
Bug 1068: Binding to a system-assigned port. OPEN
http://austingroupbugs.net/bug_view_page.php?bug_id=1068
There was a previous action from the ealier to find a volunteer to
liaise with IETF. Andrew reported he had one volunteer, and has
forwarded the details to the Core team.
We did not discuss this, but should pick up on a future call.
Bug 1073: dirname utility: algorithm for computing pathname string is stricter
than the corresponding dirname() function Accepted as marked
http://austingroupbugs.net/view.php?id=1073
This item is tagged for Issue 8
An interpretation is required.
Interpretation response:
The standard states the steps required for the dirname utility, and
conforming implementations must conform to this. However, concerns
have been raised about this which are being referred to the sponsor.
Rationale:
There is an inconsistency between the specifications of the dirname
function and utility. Additionally, it seems reasonable that the
pathname could be rationalized, removing additional <slash> characters
and "." components, and some implementations have experimented with
this.
Notes to the Editor (not part of this interpretation):
On page 76 lines 2199-2200 (XBD 3.271 Pathname), change:
except for the case of exactly two leading <slash> characters.
to:
except it is implementation-defined whether exactly two leading
<slash> characters is treated specially.
On page 625 lines 21586-21596 (XSH basename()), change:
<table>
<tr>
<td><tt>"usr"</tt></td>
<td><tt>"usr"</tt></td>
<td><tt>"."</tt></td>
<td><tt>usr</tt></td>
<td><tt>usr</tt></td>
<td><tt>.</tt></td>
</tr>
<tr>
<td><tt>"usr/"</tt></td>
<td><tt>"usr"</tt></td>
<td><tt>"."</tt></td>
<td><tt>usr/</tt></td>
<td><tt>usr</tt></td>
<td><tt>.</tt></td>
</tr>
<tr>
<td><tt>""</tt></td>
<td><tt>"."</tt></td>
<td><tt>"."</tt></td>
<td><tt>""</tt></td>
<td><tt>.</tt> or empty string</td>
<td><tt>.</tt></td>
</tr>
<tr>
<td><tt>"/"</tt></td>
<td><tt>"/"</tt></td>
<td><tt>"/"</tt></td>
<td><tt>/</tt></td>
<td><tt>/</tt></td>
<td><tt>/</tt></td>
</tr>
<tr>
<td><tt>"//"</tt></td>
<td><tt>"/"</tt> or <tt>"//"</tt></td>
<td><tt>"/"</tt> or <tt>"//"</tt></td>
<td><tt>//</tt></td>
<td><tt>/</tt> or <tt>//</tt></td>
<td><tt>/</tt> or <tt>//</tt></td>
</tr>
<tr>
<td><tt>"///"</tt></td>
<td><tt>"/"</tt></td>
<td><tt>"/"</tt></td>
<td><tt>///</tt></td>
<td><tt>/</tt></td>
<td><tt>/</tt></td>
</tr>
<tr>
<td><tt>"/usr/"</tt></td>
<td><tt>"usr"</tt></td>
<td><tt>"/"</tt></td>
<td><tt>/usr/</tt></td>
<td><tt>usr</tt></td>
<td><tt>/</tt></td>
</tr>
<tr>
<td><tt>"/usr/lib"</tt></td>
<td><tt>"lib"</tt></td>
<td><tt>"/usr"</tt></td>
<td><tt>/usr/lib</tt></td>
<td><tt>lib</tt></td>
<td><tt>/usr</tt></td>
</tr>
<tr>
<td><tt>"//usr//lib//"</tt></td>
<td><tt>"lib"</tt></td>
<td><tt>"//usr"</tt></td>
<td><tt>//usr//lib//</tt></td>
<td><tt>lib</tt></td>
<td><tt>//usr</tt></td>
</tr>
<tr>
<td><tt>"/home//dwc//test"</tt></td>
<td><tt>"test"</tt></td>
<td><tt>"/home//dwc"</tt></td>
<td><tt>/home//dwc//test</tt></td>
<td><tt>test</tt></td>
<td><tt>/home//dwc</tt></td>
</tr>
</table>
to:
<table>
<tr>
<td><tt>"usr"</tt></td>
<td><tt>"usr"</tt></td>
<td><tt>"."</tt></td>
<td><tt>usr</tt></td>
<td><tt>usr</tt></td>
<td><tt>.</tt></td>
</tr>
<tr>
<td><tt>"usr/"</tt></td>
<td><tt>"usr"</tt></td>
<td><tt>"."</tt></td>
<td><tt>usr/</tt></td>
<td><tt>usr</tt></td>
<td><tt>.</tt></td>
</tr>
<tr>
<td><tt>""</tt></td>
<td><tt>"."</tt></td>
<td><tt>"."</tt></td>
<td><tt>""</tt></td>
<td><tt>.</tt> or empty string</td>
<td><tt>.</tt></td>
</tr>
<tr>
<td><tt>"/"</tt></td>
<td><tt>"/"</tt></td>
<td><tt>"/"</tt></td>
<td><tt>/</tt></td>
<td><tt>/</tt></td>
<td><tt>/</tt></td>
</tr>
<tr>
<td><tt>"//"</tt></td>
<td><tt>"/"</tt> or <tt>"//"</tt> (see note 1)</td>
<td><tt>"/"</tt> or <tt>"//"</tt> (see note 1)</td>
<td><tt>//</tt></td>
<td><tt>/</tt> or <tt>//</tt> (see note 1)</td>
<td><tt>/</tt> or <tt>//</tt> (see note 1)</td>
</tr>
<tr>
<td><tt>"///"</tt></td>
<td><tt>"/"</tt></td>
<td><tt>"/"</tt> or <tt>"///"</tt></td>
<td><tt>///</tt></td>
<td><tt>/</tt></td>
<td><tt>/</tt> or <tt>///</tt></td>
</tr>
<tr>
<td><tt>"/usr/"</tt></td>
<td><tt>"usr"</tt></td>
<td><tt>"/"</tt></td>
<td><tt>/usr/</tt></td>
<td><tt>usr</tt></td>
<td><tt>/</tt></td>
</tr>
<tr>
<td><tt>"/usr/lib"</tt></td>
<td><tt>"lib"</tt></td>
<td><tt>"/usr"</tt></td>
<td><tt>/usr/lib</tt></td>
<td><tt>lib</tt></td>
<td><tt>/usr</tt></td>
</tr>
<tr>
<td><tt>"//usr//lib//"</tt></td>
<td><tt>"lib"</tt></td>
<td><tt>"//usr"</tt> or <tt>"/usr"</tt> (see note 1)</td>
<td><tt>//usr//lib//</tt></td>
<td><tt>lib</tt></td>
<td><tt>//usr</tt> or <tt>/usr</tt> (see note 1)</td>
</tr>
<tr>
<td><tt>"/home//dwc//test"</tt></td>
<td><tt>"test"</tt></td>
<td><tt>"/home//dwc"</tt> or <tt>"/home/dwc"</tt></td>
<td><tt>/home//dwc//test</tt></td>
<td><tt>test</tt></td>
<td><tt>/home//dwc</tt> or <tt>/home/dwc</tt></td>
</tr>
<tr>
<td><tt>"/home/.././test"</tt></td>
<td><tt>"test"</tt></td>
<td><tt>"/home/../."</tt> or <tt>"/home/.."</tt></td>
<td><tt>/home/.././test</tt></td>
<td><tt>test</tt></td>
<td><tt>/home/../.</tt> or <tt>/home/..</tt></td>
</tr>
<tr>
<td><tt>"/home/dwc/."</tt></td>
<td><tt>"."</tt></td>
<td><tt>"/home/dwc"</tt></td>
<td><tt>/home/dwc/.</tt></td>
<td><tt>.</tt></td>
<td><tt>/home/dwc</tt></td>
</tr>
</table>
note 1: Whether leading // can be converted to / depends on the
implementation-defined behavior of // (see [xref to XBD 4.13
Pathname Resolution]; although the basename() and dirname()
functions, and basename and dirname utilities, do not themselves
perform pathname resolution, their results can be passed to a
function or utility which does).
(Rows 5, 6, 9, and 10 are changed, and two new rows plus a note are added at
the end.)
On page 736 line 25067 section dirname() change:
return a pointer to a string that is a pathname of the parent
directory of that file.
to:
return a pointer to a string that is a pathname of the directory
containing the entry of the final pathname component.
On page 736 line 25072 section dirname() add a new paragraph:
It is unspecified whether redundant '/' characters and '.'
pathname components in path are removed after determining the
pathname to output. However, ".." pathname components occurring
prior to the final component shall not be removed.
On page 737 line 25113, change the RATIONALE section from:
None.
to:
An implementation should prefer the shortest output possible;
however, this is not required, in part because earlier versions
of the standard did not mention whether elision of redundant
<slash> characters or dot (".") components was permitted. Removal
of the dot-dot ("..") pathname component is not permitted,
because eliding it correctly would require performing pathname
resolution to ensure the resulting string would still point to
the correct pathname if the original string resolved as a
pathname. On implementations where pathname "//" has an
implementation-defined meaning distinct from the pathname "/",
the dirname of "//" will be "//".
On page 2667, change the entire DESCRIPTION section (lines 86879-86894) from:
The string operand shall be treated as a pathname, as defined
in [xref to XBD Section 3.271]. The string string shall be
converted to the name of the directory containing the filename
corresponding to the last pathname component in string, performing
actions equivalent to the following steps in order:
[numbered list ...]
The resulting string shall be written to standard output.
to:
The string operand shall be treated as a pathname, as defined
in [xref to XBD Section 3.271 Pathname], and shall be converted
to a pathname of the directory containing the entry of the final
pathname component. The resulting string shall be written to
standard output. The dirname utility shall not perform pathname
resolution; the result shall not be affected by whether or not
a file with the pathname string exists or by its file type.
Trailing '/' characters in string that are not also leading '/'
characters shall not be counted as part of the pathname. If the
pathname does not contain a '/', the resulting string shall be
".". If string is an empty string, the resulting string shall
be ".".
It is unspecified whether redundant '/' characters and '.'
pathname components in string are removed after determining the
pathname to output. However, ".." pathname components occurring
prior to the final component shall not be removed.
In RATIONALE, page 2668 after line 86955, insert a new paragraph:
The dirname utility is not specified in terms of the dirname()
function, because the two may produce slightly different output
where both output forms are still compliant. An implementation
should prefer the shortest output possible; however, this is
not required, in part because earlier versions of the standard
did not permit elision of redundant <slash> characters or dot
(".") components. Removal of the dot-dot ("..") pathname component
is not permitted, because eliding it correctly would require
performing pathname resolution to ensure the resulting string
would still point to the correct pathname if the original string
resolved as a pathname. On implementations where pathname "//"
has an implementation-defined meaning distinct from the pathname
"/", the dirname of "//" will be "//".
Next Steps
----------
The next call is on March 8th, 2018 (a Thursday)
Calls are anchored on US time. (8am Pacific)
This call will be for the regular 90 minutes.
Apologies in advance from Andrew
http://austingroupbugs.net
An IRC channel will be available for the meeting
irc://irc.freenode.net/austingroupbugs
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#
--------
Andrew Josey The Open Group
Austin Group Chair
Email: a.jo...@opengroup.org
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England
Tel:+44 118 9023044
