Minutes of the 5th November 2015 Teleconference Austin-737 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 6th November 2015
Attendees:
Mark Ziegast, SHware Systems
Don Cragun, IEEE PASC OR
Roger Faulkner, Oracle, The Open Group OR
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Geoff Clare, The Open Group
Eric Blake, Red Hat
Richard Hansen, BBN
David Clissold, IBM
Joerg Schilling, FOKUS Fraunhofer
Andrew Josey, The Open Group
Apologies
Martin Rehak, Oracle
* General news
A number of new bug reports have been received against TC2-2008,
they are discussed below.
The review ends on November 15 2015
* 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 26 Feb 2015)
Bug 0000887: printf and other functions appear many times in search results OPEN
http://austingroupbugs.net/view.php?id=887
Andrew is investigating.
Bug 0000900: add qsort_r OPEN
http://austingroupbugs.net/view.php?id=900
The consensus was that its a good idea to add the suggested interface.
The usual requirements regarding a sponsor for a new interface
apply.
Action: Open Group OR , to ask the Base WG if they wish to sponsor
the additional qsort interface proposed here.
Bug 0000901: reserve _POSIX* shell option namespace for future use OPEN
http://austingroupbugs.net/view.php?id=901
The forward plan for this bug remains as before:
Richard: file a new bug report with a concrete feature that
would use the _POSIX* namespace (as motivation for reserving
set -o _POSIX*)
All: debate the proposed feature. If it's something we want,
then revisit bug #901. If not, close bug #901.
Bug 0000922: Implementations should be allowed to change/remove implementation-defined environment variables OPEN
http://austingroupbugs.net/view.php?id=922
This item remains open.
Action on Eric: propose wording for Issue 8 to add secure_getenv(),
and make it clear that deleting from environment without explicit
request is not compliant, but ignoring is fine.
For Issue 7 TC 2: Create new bug to add additional conditions on
what makes TMPDIR valid, vs. undefined behavior; also add future
directions to getenv() to mention secure_getenv()
* Current Business
TC2-2008 bugs:
Bug 0000997: fclose() app usage needs "stream" in italics Accepted
http://austingroupbugs.net/view.php?id=997
Bug 0000998: Missing some changes from bug 808 Accepted
http://austingroupbugs.net/view.php?id=998
We then returned to bug 985
Bug 0000985: quote removal missing from case statement patterns and alternative expansions Accepted as marked
http://austingroupbugs.net/view.php?id=985
An interpretation is required.
This is tagged for TC3-2008
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:
None.
Notes to the Editor (not part of this interpretation):
On page 881 lines 29468-29488 (XSH fnmatch()), replace the entire DESCRIPTION with:
The fnmatch() function checks the string specified by the string
argument to see if it matches the pattern specified by the
pattern argument.
The pattern argument is a pattern that matches a string according
to the following rules. Historically, pattern matching notation
is related to, but slightly different from, the regular expression
notation described in [xref to XBD Chapter 9]. For this reason,
the description of the rules for this pattern matching notation
are based on the description of regular expression notation,
modified to account for the differences.
Special Pattern Characters: When unescaped and outside a
bracket expression, the following characters shall have
special meaning in the specification of patterns:
? A is a pattern that shall
match any character, subject to the value of the flags
argument as described below.
* An is a pattern that shall match
zero or more characters according to the rules described
below.
[ A introduces a bracket
expression, subject to the values of pattern and flags
as described below. The meaning of a bracket expression
is as described in [xref to XBD Section 9.3.5], except
that the character (’!’)
shall replace the character (’ˆ’)
in its role in a non-matching list in the regular
expression notation, and the value of flags can further
limit which characters match a bracket expression. A
bracket expression starting with a character
produces unspecified results.
\ A character escapes the following
character, subject to the value of the flags argument
as described below.
Patterns Matching a Single Character: The following patterns
shall match a single character: ordinary characters,
characters that have been escaped, and pattern bracket
expressions. The pattern bracket expression also shall match
a single collating element. An ordinary character is a
pattern that shall match itself. It can be any character
in the supported character set except for NUL and the above
special pattern characters. Matching shall be based on the
bit pattern used for encoding the character, not on the
graphic representation of the character. An escaped character
shall match itself according to the rules for ordinary
characters.
Patterns Matching Multiple Characters: The following rules
are used to construct patterns matching multiple characters
from patterns matching a single character:
An unescaped (’*’) is a pattern
that shall match any string, including the null string,
subject to the value of the flags argument as described
below.
The concatenation of patterns matching a single character
is a valid pattern that shall match the concatenation
of the single characters or collating elements matched
by each of the concatenated patterns.
The concatenation of one or more patterns matching a
single character with one or more unescaped
characters is a valid pattern. In such patterns, each
shall match a string of zero or more characters,
matching the greatest possible number of characters
that still allows the remainder of the pattern to match
the string.
The flags argument shall modify the interpretation of pattern
and string. It is the bitwise-inclusive OR of zero or more of
the flags defined in .
If the FNM_PATHNAME flag is set in flags, then a character
('/') in string shall not be matched by either the
or special characters, nor by a
bracket expression. In addition, if a character is
discovered after an unescaped that is not
in a bracket expression and before a corresponding
, the shall be
treated as an ordinary character. For example, if the FNM_PATHNAME
flag is set, the pattern "a[b/c]d" does not match the
strings "abd" or "a/d". It only matches the
string "a[b/c]d".
If FNM_NOESCAPE is set in flags, a character in
pattern shall be treated as an ordinary character.
If FNM_PERIOD is set in flags and either of the following is
true regarding a in string:
the is the first character of string
FNM_PATHNAME is set in flags and the immediately
follows a character
then the shall not be matched by:
An unescaped pattern.
An unescaped pattern.
A bracket expression containing a non-matching list (such
as "[!a]"), a range expression (such as
"[%−0]"), or a character class expression (such
as "[[:punct:]]"). It is unspecified whether an
explicit in a bracket expression matching list,
such as "[.abc]", can match the .
On page 882 after line 29507 (fnmatch() rationale), insert the
following new paragraph above the existing rationale:
For the rationale behind the pattern matching behavior, see [xref to XRAT C.2.13].
On page 1095 lines 36821-36823 (glob() DESCRIPTION), change:
The glob() function is a pathname generator that shall implement
the rules defined in XCU Section 2.13 (on page 2354), with
optional support for rule 3 in XCU Section 2.13.3 (on page
2355).
to:
The glob() function is a pathname generator that shall implement
the rules defined in [xref to XCU Section 2.13], with optional
support for the rule in [xref to XCU Section 2.13.1].
On page 1096 lines 36856-36858 (glob() DESCRIPTION), change:
GLOB_NOCHECK Supports rule 3 in XCU Section 2.13.3 (on page
2355). If pattern does not match any pathname, then glob() shall
return a list consisting of only pattern, and the number of
matched pathnames is 1.
to:
GLOB_NOCHECK Supports the rule in [xref to XCU Section 2.13.1].
If pattern does not match any pathname, then glob() shall provide
a list consisting of only pattern, and the number of matched
pathnames is 1.
On page 2327 line 73887 (XCU 2.6 Word Expansions), change:
4. Quote removal (see Section 2.6.7) shall always be performed
last.
to:
4. Quote removal (see Section 2.6.7) shall always be performed,
and shall always be performed last.
On page 2332 lines 74101-74103 (XCU 2.6.4 Arithmetic Expansion), change:
The expression shall be treated as if it were in double-quotes,
except that a double-quote inside the expression is not treated
specially. The shell shall expand all tokens in the expression
for parameter expansion, command substitution, and quote removal.
to:
The expression shall be expanded as if it were a word in
double-quotes, except that the treatment of a double-quote
inside the expression is unspecified and the result of parameter
expansion of the '@' special parameter is unspecified.
On page 2333 lines 74154-74155 (XCU 2.6.6 Pathname Expansion), change:
After field splitting, if set -f is not in effect, each field
in the resulting command line shall be expanded using the
algorithm described in Section 2.13, qualified by the rules in
Section 2.13.3.
to:
After field splitting, if set -f is not in effect, each field
in the resulting command line shall be expanded using the
algorithm described in [xref to Section 2.13].
On page 2345 lines 74601-74605 (XCU 2.9.4.3 Case Conditional Construct), change:
In order from the beginning to the end of the case statement,
each pattern that labels a compound-list shall be subjected to
tilde expansion, parameter expansion, command substitution, and
arithmetic expansion, and the result of these expansions shall
be compared against the expansion of word, according to the
rules described in Section 2.13 (which also describes the effect
of quoting parts of the pattern).
to:
In order from the beginning to the end of the case statement,
each pattern that labels a compound-list shall be subjected to
tilde expansion, parameter expansion, command substitution,
arithmetic expansion, and quote removal, and the result of these
expansions shall be compared against the expansion of word,
according to the rules described in Section 2.13.
On pages 2354-2354, replace all of XCU Section 2.13 with:
2.13 Pattern Matching Notation
A string str shall match a pattern patt if the fnmatch() function
(see [xref to XSH fnmatch()]) would return 0 if called with the
following arguments:
the first argument (pattern) is the same as patt, except
each character that was quoted in patt and is not in a
bracket expression is prefixed by a backslash
the second argument (string) is str
the third argument (flags) is FNM_PATHNAME|FNM_PERIOD
when the pattern is being used for pathname expansion and
0 otherwise
2.13.1 Matching Against Existing Filenames and Pathnames
When the pattern is being used for pathname expansion, [copy
of text from 2.13.3 item 3].
On page 2762 lines 90501-90502 (find -name primary), change:
The additional rules in Section 2.13.3 (on page 2355) do not
apply as this is a matching operation, not an expansion.
to:
The pathname expansion rules in [xref to Section 2.13] do not
apply as this is a matching operation, not a pathname expansion.
On page 2762 lines 90505-90507 (find -path primary), change:
The additional rules in Section 2.13.3 (on page 2355) do not
apply as this is a matching operation, not an expansion.
to:
The pathname expansion rules in [xref to Section 2.13] do not
apply as this is a matching operation, not a pathname expansion.
On page 3035 line 100791 (XCU pax) change:
... described in Section 2.13.1 (on page 2354) and Section
2.13.2 (on page 2355).
to:
... described in Section 2.13 (on page 2354).
On page 3041 lines 101078-101079 (XCU pax, pattern operand) change:
... including the filename expansion rules in Section 2.13.3 (on page 2355).
to:
... including the pathname expansion rules but matching the
pathnames in the archive instead of pathnames in the file
hierarchy.
On page 3701 lines 126644-126645 (XRAT C.2.13) change:
C.2.13.1 Patterns Matching a Single Character
Both quoting and escaping are described here because pattern matching must work ...
to:
Patterns Matching a Single Character
Pattern matching must work ...
On page 3701 line 126672 and page 3702 line 126680 change the section C.2.13.2 and C.2.13.3 headings to be unnumbered headings.
On page 3702 line 126693 add a new section:
C.2.13.1 Matching Against Existing Filenames and Pathnames
There is no additional rationale provided for this section.
Bug #249: Add standard support for $'...' in shell Reopened
http://austingroupbugs.net/bug_view_page.php?bug_id=249
We will also continue with this next week.
See http://posix.rhansen.org:9001/p/bug249
Next Steps
----------
The next call is on November 12, 2015 (a Thursday)
Andew will bring up the bridge.
Calls are anchored on US time. (8am Pacific)
This call will be for the regular 90 minutes.
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:
http://posix@posix.rhansen.org:9001/p/201x-mm-dd
password=2115756#