Minutes of the 25 August 2011 Teleconference Austin-535 Page 1 of 1 Submitted by Andrew Josey, The Open Group. August 26 , 2011 Attendees Andrew Josey, The Open Group Don Cragun, PASC OR Mark Brown, IBM, TOG OR Eric Blake, Red Hat Jim Pugsley, Oracle Geoff Clare, The Open Group Nick Stoughton, USENIX, ISO/IEC OR Andrew explained that he had to reissue TC1 draft 3 after identifying some problems in the changed build system - notably the rationale generator - that had corrupted the document. Due to this we are extending the review by a few days. We also discussed development of the merged draft, and that at the moment we have a shortage of editorial resource, which could cause a delay to the schedule Action: Andrew to ship final TC1 draft 3 to IEEE for mandatory editorial coordination. * Old Business Bug 281 sort -M http://austingroupbugs.net/view.php?id=281 Don has been attempting to follow up with Roger directly, but so far had not received a response. * New Business Bug 0000351: certain shell special built-ins should expand arguments in assignment context Accepted as Marked http://austingroupbugs.net/view.php?id=351 After comments were raised on the reflector in mail seq 16402, the bug was discussed at the 25 August 2011 teleconference, and the proposed interpretation was revised. The review time for the interpretation is being restarted. This revised Interpretation was proposed 26 August 2011 for final 30 day review Interpretation response The standard states that the current behavior of ksh93 does not conform, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Rationale: Some shells behave as specified; some others match ksh93 behavior; and others have gone different routes. Notes to the Editor (not part of this interpretation): New definition in XBD 3: Declaration Utility A utility which can take arguments that cause variable assignments (of the form varname=value) which will persist in the current shell environment. When the shell recognizes a declaration utility as the command name, subsequent arguments that would be a valid variable assignment in isolation are subject to different expansion rules (field splitting and pathname expansion are suppressed, and tilde expansion occurs after the and any unquoted ). Arguments which are not a valid variable assignment in isolation are processed according to normal argument expansion rules. The following standard utilities are declaration utilities: export, readonly, and, under certain conditions, command. An implementation may provide other declaration utilities. At line 3276, XBD 4.22 Variable Assignment, add: Assignment context occurs in the cmd_prefix portion of a shell simple command, as well as in arguments of a recognized declaration utility. At line 71964, XCU 1.4 Utility Description Defaults DESCRIPTION, add: A standard utility shall not be treated as a declaration utility unless explicitly stated in this section. At line 73093 (XCU 2.9.1 step 2), add: If the command name is recognized as a declaration utility, then any remaining words that would be recognized as a variable assignment in isolation shall be expanded as a variable assignment (tilde expansion after the first and after any unquoted , parameter expansion, command substitution, arithmetic expansion, and quote removal, but no field splitting or pathname expansion); while words that would not be a variable assignment in isolation shall be subject to regular expansion. For all other command names, all subsequent words shall be subject to regular expansion (tilde expansion for only a leading , parameter expansion, command substitution, arithmetic expansion, field splitting, pathname expansion, and quote removal). After line 73100, add a paragraph: When determining whether a command name is a declaration utility, an implementation may use only lexical analysis. It is unspecified whether assignment context will be used if the command name would only become recognized as a declaration utility after word expansions. At line 74276 (XCU export DESCRIPTION), add: The export special built-in shall be a declaration utility. Therefore, if export is recognized as the command word of a simple command, then subsequent words of the form name=word shall be expanded in an assignment context. See Section 2.9.1. At line 74360 (XCU readonly DESCRIPTION), add: The readonly special built-in shall be a declaration utility. Therefore, if readonly is recognized as the command word of a simple command, then subsequent words of the form name=word shall be expanded in an assignment context. See Section 2.9.1. At line 81462 (XCU command DESCRIPTION), add: The command utility shall be treated as a declaration utility if the first argument passed to the utility is recognized as a declaration utility. In this case, subsequent words of the form name=word shall be expanded in an assignment context. See Section 2.9.1. At line 81588 (XCU command APPLICATION USAGE), add: The command utility takes on the expansion behavior of the command that it is wrapping. Therefore, in command command export a=~ command is recognized as a declaration utility, and the command sets the variable a to the value of $HOME because it performs tilde-expansion of an assignment context; while command echo a=~ outputs the literal string "a=~" because regular expansion can only perform tilde-expansion at the beginning of the word. However, the shell need only perform lexical analysis of the next argument when deciding if command should be treated as a declaration utility; therefore, with: var=export; command $var a=~ and command -- export a=~ it is unspecified whether the word 'a=~' is handled in an assignment context or as a regular expansion. At line 124658 (XRAT C.2.9.1), add: Expansion of words in an assignment context following the command word can only occur for declaration utilities, and only when the word can be used as a variable assignment in isolation. For example, this code sequence exports the single variable a with the value '1 b=2', but invokes make with the macro a set to '1' and b set to '2', since make is not a declaration utility: $ set '1 b=2' $ export a=$1 $ make a=$1 Conversely, this code sequence exports two variables, a set to '1' and b set to '2', because the use of quoting means that the word could not be recognized as a variable assignment, and regular expansion rules require that field splitting occurs on the unquoted expansion of $1: $ set '1 b=2' $ export \a=$1 Likewise, this code sequence will not be parsed in assignment context, but is still required to export the variable named foo with the value 1: $ var=foo $ export $var=1 Implementations are permitted to provide extensions that serve as declaration utilities, such as 'typeset' or 'local', or even a way to define a function that can behave as a declaration utility. Declaration utilities are only required to be recognized via lexical analysis; if any expansions are required before the command name is known, or before the first argument to the command utility is known, then it is unspecified whether subsequent arguments will be treated with an assignment context during expansion. For example, it is unspecified whether 'var=export; $var a=~' sets the variable a to a literal or to the value of $HOME, since lexical analysis sees '$var' rather than 'export' as the command name. We picked up on the Issue 7 bugs * Issue 7 bugs Bug 0000478: Should cmp -s write to stderr when an error occurs? http://austingroupbugs.net/view.php?id=478 This item is tagged for TC2-2008. An interpretation is required. 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: Existing implementations have adopted both possible interpretations of the current wording. Notes to the Editor (not part of this interpretation): On L9875 (L81246 in Issue 7) change the -s description from: Write nothing for differing files; return exit status only. to: Write nothing to standard output or standard error when files differ; indicate differing files through exit status only. It is unspecified whether a diagnostic message is written to standard error when an error is encountered; if a message is not written, the error is indicated through exit status only. After L9924 (L81295 in Issue 7) append to STDERR: If the -s option is used and an error occurs, it is unspecified whether a diagnostic message is written to standard error. After L9944 (L81314 in Issue 7) append to APPLICATION USAGE: Since the behavior of -s differs between implementations as to whether error messages are written, the only way to ensure consistent behavior of cmp when -s is used is to redirect standard error to /dev/null. If error messages are wanted, instead of using -s standard output should be redirected to /dev/null, and anything written to standard error should be discarded if the exit status is 1. For example: silent_cmp() { # compare files with no output except error messages message=$(cmp "$@" 2>&1 >/dev/null) status=$? case $status in (0|1) ;; (*) printf '%s\n' "$message" ;; esac return $status } At page 2534 line 81336 (FUTURE DIRECTIONS), change "None" to "Future versions of this standard may require that diagnostic messages are written to standard error when the -s option is specified" Bug 0000484: Ambiguity of "first lock" in F_GETLK OPEN http://austingroupbugs.net/view.php?id=484 It was agreed that we need to inspect source code of various implementation to determine current behavior. Action: Eric to check Linux and cygwin. Action: Jim to check Solaris Action: Andrew to email Mark to request him to check AIX We addressed the TC1-2008 bug: Bug 0000488: typos in tc1 draft3 Accepted as marked http://austingroupbugs.net/view.php?id=488 At page 250 line 8515 [XSH/TC1/D2/0686], (xsh page 2151) in the Rationale: change "flush()" to "fflush()". At page 251 line 8551 [XSH/TC1/D2/0689], (xsh page 2152) in the Rationale: change "flush()" to "fflush()". Bug 0000485: Unclear explanation about when last file status change timestamp shall be updated OPEN http://austingroupbugs.net/view.php?id=485 We agreed to start with this bug on the next call Next Steps ---------- The next call is on September 1st at 08:00 Pacific and will continue processing defect reports. We will start at bug 485 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.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