Minutes of the 2 Sep 2010 Teleconference Austin-495 Page 1 of 1 Submitted by Andrew Josey, The Open Group. September 3rd , 2010 Attendees Andrew Josey, The Open Group Don Cragun, PASC OR Nick Stoughton, USENIX, ISO/IEC OR Eric Blake, Red Hat Mark Brown, IBM, TOG OR Geoff Clare, The Open Group Apologies Ulrich Drepper, Red Hat * Old Business +TC1 planning Andrew had circulated an email with next steps to commence a technical corrigendum and has also now tagged an initial set of candidate items. A discussion followed about what other items need to be included. There are three classes of item to consider: 1. Aardvark from issue 6 that was not included in the revision (and not logged in SD5/Change History) nor an interpretation. This is likely to be XSHbug2.txt after ERN 234, XBDbug2.txt after ERN 105, XCUbug2.txt after ERN 174. Action: Andrew to identify which ERNs need to be considered. 2. Issue 6 Mantis Bugs not addressed in the revision. Action: Don will identify candidate items 3. Issue 7 interpretations with non controversial changes. Open -- no volunteer assigned yet. * New business +Interpretations status The 30 day review period has ended on the interpretations batch that commenced its review on July 30 Mantis bugs :221, 240, 252, 254, 255, 256, 257, 258, 259, 261, 262, 283, 292 There was an issue raised on item 255 (see below). Action: Andrew to finalize the current batch apart from Bug 255. Action: Andrew to start a new batch of interpretations for 30 day review. We discussed interpretation 255 for which a comment had been raised: Bug 0000255: shell expansions in assignments that precede a command name OPEN http://austingroupbugs.net/view.php?id=255 --Comment: Are we still missing text regarding side-effects of expansions performed during step 2. That is, is there a guarantee that: unset a; test "${a=b}"; echo ${a+set} will always echo "set", or does the proposed wording still permit an implementation to fork upon recognizing that test is a simple command that is not a special built in, prior to expanding "${a=b}", such that the subsequent echo still sees $a as unset? --end comment A response was posted in mail seq 14431 which we added as a note to the bug: (from DGK, mail seq austin-group-l:archive/latest/14431) --quote I don't think that this was ever an issue. Command arguments are always expanded in the current environment whether the command is built-in or not. In fact you might not know the command until the arguments are expanded. Thus, a will be set. The only area of contention that I am aware of is unset a; "${a=b}" test ; echo ${a-set} since some shells expand could expand parameter assignment lists in a subshell environment. The Bourne shell, for example, forked() after expanding command arguments when the command was not a built-in. --end quote It was proposed that we add some additional rationale to XRAT 2.2.9.1 p3664 after line 124658 The exact text is to be determined so this item is left OPEN for now. Bug 0000293: restricting readdir normalization of filenames Accepted as Marked http://austingroupbugs.net/view.php?id=293 We then revisited bug 293, for which some comments had been raised on the reflector -- can a filesystem reject a filename with a leading dash? This was discussed , and revised wording agreed, which was added to bugnote 531. Bug 0000299: what's the exit status when a shell aborts on using the dot built in when the argument is not readable Accepted as Marked http://austingroupbugs.net/view.php?id=299 At page 3175 line 105724 section sh change 1-125 A non-interactive shell detected a syntax, redirection, or variable assignment error. to 1-125 A non-interactive shell detected an error other than command_file not found, including but not limited to syntax, redirection, or variable assignment errors. Next Steps ---------- The next call will be on September 9th at 16:00 UK time/08:00 Pacific and will continue processing defect reports. http://austingroupbugs.net See the calendar for the list of dialup numbers. An IRC channel will be available for the meeting irc://irc.freestandards.org #austin 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