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 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 characters. to: except it is implementation-defined whether exactly two leading characters is treated specially. On page 625 lines 21586-21596 (XSH basename()), change:
"usr" "usr" "." usr usr .
"usr/" "usr" "." usr/ usr .
"" "." "." "" . or empty string .
"/" "/" "/" / / /
"//" "/" or "//" "/" or "//" // / or // / or //
"///" "/" "/" /// / /
"/usr/" "usr" "/" /usr/ usr /
"/usr/lib" "lib" "/usr" /usr/lib lib /usr
"//usr//lib//" "lib" "//usr" //usr//lib// lib //usr
"/home//dwc//test" "test" "/home//dwc" /home//dwc//test test /home//dwc
to:
"usr" "usr" "." usr usr .
"usr/" "usr" "." usr/ usr .
"" "." "." "" . or empty string .
"/" "/" "/" / / /
"//" "/" or "//" (see note 1) "/" or "//" (see note 1) // / or // (see note 1) / or // (see note 1)
"///" "/" "/" or "///" /// / / or ///
"/usr/" "usr" "/" /usr/ usr /
"/usr/lib" "lib" "/usr" /usr/lib lib /usr
"//usr//lib//" "lib" "//usr" or "/usr" (see note 1) //usr//lib// lib //usr or /usr (see note 1)
"/home//dwc//test" "test" "/home//dwc" or "/home/dwc" /home//dwc//test test /home//dwc or /home/dwc
"/home/.././test" "test" "/home/../." or "/home/.." /home/.././test test /home/../. or /home/..
"/home/dwc/." "." "/home/dwc" /home/dwc/. . /home/dwc
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 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 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#