Minutes of the 9 February 2012 Teleconference Austin-548 Page 1 of 1 Submitted by Andrew Josey, The Open Group. February 10 , 2012 Attendees Andrew Josey, The Open Group Don Cragun, PASC OR Mark Brown, IBM, TOG OR Geoff Clare, The Open Group Nick Stoughton, USENIX, ISO/IEC OR Eric Blake, Red Hat Jim Pugsley, Oracle Joerg Schilling, Fraunhofer Society The TC1-2008 Draft 4 document merger into the Base Specs is still progressing, XBD, XCU and XRAT are now complete, and XSH is now over 50% complete. * Old Business Bug 0000251: Forbid newline, or even bytes 1 through 31 (inclusive), in filenames OPEN http://austingroupbugs.net/view.php?id=251 This bug will remain open until after TC1 is approved Correction to the last minutes. Bug 0000539: tighten du regarding files encountered through multiple command line arguments http://austingroupbugs.net/view.php?id=539 Related to Bug 0000527, We also agreed to file a bug report (AI to Eric) to implement the Future Directions in Issue 8. Don agreed to take an AI to resolve the bug after Eric filed it. Eric filed the bug (0000539: tighten du regarding files encountered through multiple command line arguments) and after reviewing it to be sure that it specified what we agreed to during the meeting, Don marked it resolved, accepted with an Issue 8 tag. *New business Bug 0000535: require support for path separator in function and alias names Rejected http://austingroupbugs.net/view.php?id=535 This bug had been reopened since the last meeting. On Jan 15, Jilles Tjoelker sent this response in email: A shell may allow defining such a function, but shall not allow calling it. In XCU 2.9.1.1 Command Search and Execution, if the command name contains a , the shell shall perform actions equivalent to calling execve(); functions and shell builtins apply only if the command name does not contain a . Allowing a in an alias name looks like a valid extension. Although allowing propagation gives more flexibility, it also makes the execution environment less predictable. Instead, the called script can source the definitions again, or the called script can be sourced (possibly in a subshell environment so it cannot modify the parent environment). On that basis, the Austin Group still believes that mandating the use of is not appropriate for the standard, but implementations may still offer it as an extension for aliases, and that it makes no sense for functions. Bug 0000529: fildes unspecified on close()'s [EINTR] Accepted as Marked http://austingroupbugs.net/view.php?id=529 Geoff took an action to update Bug note 1107 (now completed). This bug is now targeted for Issue 8 (rather than TC2) Interpretation response: The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: Currently implementations can choose whether to close the file descriptor when close() returns an [EINTR] error. This is unsatisfactory since multithreaded applications need to know whether the file descriptor has been closed in order to know whether it is safe to call close() again. Notes to the Editor (not part of this interpretation): Change: If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to [EINTR] and the state of fildes is unspecified. If an I/O error occurred while reading from or writing to the file system during close( ), it may return -1 with errno set to [EIO]; if this error is returned, the state of fildes is unspecified. to: If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to [EINTR] and fildes shall remain open; however, it is unspecified whether fildes can subsequently be passed to any function except close() without error. If any error other than [EINTR] and [EBADF] occurs, close() shall return -1 with errno set to the corresponding error number and shall close fildes. After line 22924 add a new paragraph to the end of the ERRORS section: The close() function shall not return an [EAGAIN] or [EWOULDBLOCK] error. After line 22966 add the following new paragraphs in the RATIONALE section: Earlier versions of this standard left the state of fildes unspecified after [EINTR] and [EIO] errors. This was unsatisfactory once threads were introduced, since multithreaded applications need to know whether fildes has been closed. They cannot simply call close() again regardless, because if fildes was closed by the first call another thread could have been allocated a file descriptor with the same value as fildes. The alternative of never retrying close() would lead to a file descriptor leak whenever close() did not close fildes. This standard now requires that close() leaves the file descriptor open on [EINTR] errors and closes the file descriptor for all other errors (except [EBADF]). Leaving the file descriptor open on [EINTR] is necessary so that the application can call close() again to continue to wait for the close operation to complete; in some cases there is no other portable way for the application to know when the event that close() was waiting for when it was interrupted has completed (for example, a tape drive rewinding). Although the file descriptor is left open on [EINTR], it might no longer be usable; that is, passing it to any function except close() might result in an error such as [EIO]. The standard developers considered introducing a thread-locale variable that close() would set to indicate whether it had closed fildes when returning -1. However, this was rejected in favor of the simpler solution of requiring close() to close fildes for all errors except [EINTR] (and [EBADF]). Application writers then have a simple rule to follow when close() returns -1: it is safe to retry the close() if errno is [EINTR], otherwise it is not safe. Requiring or allowing the file descriptor to be left open after an [EIO] error could lead to the situation where it is uncloseable because all subsequent repeat attempts just produce another [EIO] error. Another consideration was whether implementations might return [EAGAIN] as an extension and whether close() should be required to leave the file descriptor open in this case, since [EAGAIN] normally implies an operation should be retried. It seemed very unlikely that any implementation would have a legitimate reason to return [EAGAIN] and therefore this requirement would mean applications have to include code for the [EAGAIN] case that will never be used. Therefore close() is now forbidden from returning [EAGAIN] errors. Likewise for [EWOULDBLOCK]. Bug 0000537: for set -e, compound commands and functions case should be clarified OPEN http://austingroupbugs.net/view.php?id=537 The group has developed a possible resolution to this issue in bugnote 1118 and copied below, and would appreciate comments back from shell maintainers. AI: Andrew to contact Chet Ramey and Dave Korn to request their feedback. Bugnote 1118: If anything, the way to go about this would be to keep 'set -e' unchanged in behavior by default, where there are contexts (such as functions) where reusing 'set -e' has no effect because of the calling context; and then go about getting consensus among the various shell implementers about adding a new set option (maybe named 'set -o errreset'; good luck in finding a short option name that works for all the shells) that lifts the restriction about contexts where 'set -e' is ignored. That is: f() { set -e; false; echo hello; }; if f; then :; fi would continue to echo hello, but: f() { set -e; false; echo hello; }; set -o errreset; if f; then :; fi would let the set -e inside f() take effect, and inhibit the echo. By doing this, scripts written to the behavior of 0000052 will continue to work, and new scripts can opt-in to the more intuitive semantics. Bug 0000540: Add API for adding entries to user accounting database by passing a pseudo-terminal master file descriptor Rejected http://austingroupbugs.net/view.php?id=540 This item is rejected as out of scope since it proposes a new API. The Austin Group has a specific process which needs to be followed for proposals for new APIs to bring them into scope. See Austin/112r3 and Austin/164 for details. See the text starting : New Work Items : in http://www.opengroup.org/austin/docs/austin_112r3.txt Also see the diagram in: http://www.opengroup.org/austin/docs/austin_164.pdf Bug 0000541: pathname resolution of a symlink containing exactly // Accepted http://austingroupbugs.net/view.php?id=541 This item is tagged for TC2-2008. An interpretation is required. Interpretation response The standard states that the characters in a symlink are prepended to the remainder of the pathname being resolved, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: This is not historic practice on implementation that support //hostname as a special case in pathname resolution. For implementation that don't treat // as special, this change has no effect on pathname resolution. Therefore, this change seems suitable as a technical corrigenda fix. Notes to the Editor (not part of this interpretation): Make the changes listed in the Desired Action. Next Steps ---------- The next call is on February 16 and will continue processing defect reports. This call will be for the regular 90 minutes. http://austingroupbugs.net See the calendar for the list of dialup numbers. An IRC channel will be available for the meeting irc://irc.freenode.org/austingroupbugs ICAL: http://www.google.com/calendar/ical/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic XML: http://www.google.com/calendar/feeds/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic