0000985: quote removal missing from case statement patterns and alternative expansions

Notes
(0002835) geoffclare (manager) 2015-09-18 08:39	The proposed change to 2.6.2 conflicts with the one in 0000221, which updates just the ${parameter:=word} expansion to mention quote removal (see Note: 0000399). We looked at this area thoroughly when we worked on bug 221, so I believe the change made there is the correct one, and only the change to 2.9.4.3 in this new bug should be made.

(0002839) shware_systems (reporter) 2015-09-18 20:08 edited on: 2015-09-18 20:18	To make the change clearer, I feel word should be changed to WORD, to match the token format of the grammar and emphasize in these contexts that way that quote removal is required (already) when these WORDs are evaluated, whatever recursion depth they have been detected at. Similar text that applies to command substitutions, making explicit that command represents the list production of the grammar, might be useful also.

(0002852) rhansen (manager) 2015-10-01 18:29	Note: 0000399 in 0000221 seems to only address the case when the parameter expansion happens inside double quotes. What about quote removal in word when the parameter expansion happens outside of double quotes?

(0002853) geoffclare (manager) 2015-10-02 08:45	Expansion outside of double quotes is covered by the page 2306 line 72721 change in Note: 0000399 Note that it is only in the assignment case that quote removal is applied directly to word as part of the expansion. In the other cases, quote removal happens after the expansion, as normal. To illustrate: $ unset unsetvar; printf '%s\n' ${unsetvar-"foo bar"} foo bar $ unset unsetvar; printf '%s\n' ${unsetvar="foo bar"} foo bar

(0002855) rhansen (manager) 2015-10-02 17:13	The page 2306 line 72721 change only changes default assignment expansions (${parameter:=word}). I still don't see where the standard says that quote removal happens with ${unsetvar-"foo bar"}.

(0002856) shware_systems (reporter) 2015-10-03 00:57	Lines 73875-9 and 74050-2, in C138.pdf, is what I see as governing word in ${parameter[op[word]]}, and includes quote removal explicitly. The example in 74052 simply uses ## as representative of generic op. The restriction to those expansions in Line 73944 means any substitutions occur in the context of a single word, not that quote removal doesn't apply to the final value. The parameter field is conceptually a NAME token, in the grammar, which can get converted to ASSIGNMENT_WORD depending on the operator. The values they reference, when set, have already had quote removal performed.

(0002858) geoffclare (manager) 2015-10-04 07:52	Quote removal for the assignment case is mentioned explicitly because it is done differently. There is nothing special about quote removal for ${unsetvar-"foo bar"} - it happens in the normal way for word expansions, as per section 2.6 (lines 73875-9 as pointed out by shware_systems, and also lines 73880-7).

(0002863) rhansen (manager) 2015-10-08 16:14 edited on: 2015-10-15 15:55	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 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.

(0002864) rhansen (manager) 2015-10-08 16:31	Note: 0002863 is close, but we still need to: say that field splitting doesn't occur for arithmetic expansion's expression expansion (in case the expression has $@ in it) possibly add an interpretation

(0002865) geoffclare (manager) 2015-10-08 16:40 edited on: 2015-10-15 15:56	Regarding point 1, saying that field splitting doesn't occur will have the effect that the behaviour for $@ inside $((...)) is unspecified (see 0000888). So it might be simpler just to say directly that the behaviour for $@ inside $((...)) is unspecified. E.g.: 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. Update: Note: 0002863 has been edited to make this change.

(0002866) shware_systems (reporter) 2015-10-08 20:39	Additionally, it appears this change is desirable, in XCU 2.3, 73683-4: 9. If the previous character was part of a word, the current character shall be appended to that word. to: 9. If the previous character was part of a word, the current character shall be appended to that word, unless it matches a character the grammar or an expansion specifies as a context dependent character, or initial character of a sequence, that delimits aspects of how the token or expansion is to be evaluated. Ed.: the sequence clause accounts for the '(' ')' terminating NAME in function definitions, and the parameter expansion operators. For arithmetic expansions, it should probably be explicit that to evaluate 'x' as an integer constant alias, \'x\' is the form to use.

(0002884) rhansen (manager) 2015-11-05 17:09	Some issues were discovered in the proposed wording after this bug report was marked as resolved. A new comment containing new proposed wording will be added shortly.

(0002885) rhansen (manager) 2015-11-05 17:17 edited on: 2019-09-23 15:50	OLD Interpretation response (superseded by Note: 0004562) ------------------------ 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: <tt>?</tt> A <question-mark> is a pattern that shall match any character, subject to the value of the flags argument as described below. <tt></tt> An <asterisk> is a pattern that shall match zero or more characters according to the rules described below. <tt>[</tt> A <left-square-bracket> 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 <exclamation-mark> character (<tt>’!’</tt>) shall replace the <circumflex> character (<tt>’ˆ’</tt>) 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 <circumflex> character produces unspecified results. <tt>\</tt> A <backslash> 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 <asterisk> (<tt>’’</tt>) 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 <asterisk> characters is a valid pattern. In such patterns, each <asterisk> 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 <fnmatch.h>. If the FNM_PATHNAME flag is set in flags, then a <slash> character (<tt>'/'</tt>) in string shall not be matched by either the <asterisk> or <question-mark> special characters, nor by a bracket expression. In addition, if a <slash> character is discovered after an unescaped <left-square-bracket> that is not in a bracket expression and before a corresponding <right-square-bracket>, the <left-square-bracket> shall be treated as an ordinary character. For example, if the FNM_PATHNAME flag is set, the pattern <tt>"a[b/c]d"</tt> does not match the strings <tt>"abd"</tt> or <tt>"a/d"</tt>. It only matches the string <tt>"a[b/c]d"</tt>. If FNM_NOESCAPE is set in flags, a <backslash> 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 <period> in string: the <period> is the first character of string FNM_PATHNAME is set in flags and the <period> immediately follows a <slash> character then the <period> shall not be matched by: An unescaped <asterisk> pattern. An unescaped <question-mark> pattern. A bracket expression containing a non-matching list (such as <tt>"[!a]"</tt>), a range expression (such as <tt>"[%−0]"</tt>), or a character class expression (such as <tt>"[[:punct:]]"</tt>). It is unspecified whether an explicit <period> in a bracket expression matching list, such as <tt>"[.abc]"</tt>, can match the <period>. 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 <tt>FNM_PATHNAME\|FNM_PERIOD</tt> 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.

(0003522) ajosey (manager) 2016-12-15 18:11	Interpretation proposed: 15 Dec 2016

(0003550) ajosey (manager) 2017-01-18 15:24	Interpretation Approved: 18 Jan 2017

(0003947) geoffclare (manager) 2018-04-11 15:54	Reopening based on email discussion about quoting within bracket expressions. It seems that the shell cannot use fnmatch() to do pattern matching because of cases such as ["a-c"] which becomes [a-c] after quote removal but with no way to tell fnmatch() that the originally quoted '-' should be treated literally, since backslash is not special inside bracket expressions. (The shell could pass "[-ac]" for this specific case, but rearrangement is not a general solution.) Given that the shell cannot use fnmatch(), there does not seem to be any point in trying to specify the behaviour in terms of an fnmatch() call. We should revert to a solution like the previous one (i.e. Note: 0002863 with the issues mentioned in Note: 0002884 addressed in a different way).

(0003948) geoffclare (manager) 2018-04-12 08:11	On second thoughts, while the behaviour can't be specified in terms of an fnmatch() call, perhaps it can still be done by reference to the fnmatch() description. Here's a suggested new version of 2.13 to replace the one in Note: 0002885: 2.13 Pattern Matching Notation The shell shall perform pattern matching as described for the fnmatch() function (see [xref to XSH fnmatch()]) with the third argument (flags) set to <tt>FNM_PATHNAME\|FNM_PERIOD</tt> when the pattern is being used for pathname expansion and 0 otherwise, except that: If quote removal (see Section 2.6.7) has already been performed on the pattern (as, for example, in a case compound command), each character that was quoted by the quote characters that were removed when quote removal was performed shall be treated as a literal character. If quote removal has not yet been performed on the pattern, the quote characters that will be removed when quote removal is performed shall not be considered to be part of the pattern and each character that is quoted by those quote characters shall be treated as a literal character.

(0003970) joerg (reporter) 2018-04-17 13:46 edited on: 2018-04-17 13:50	In the Bourne Shell and in ksh88, the case statement first tries to match the case argument against the pattern using gmatch() and in case this does not result in a match, the quoting on the pattern is removed and a plain string compare is done. In case of the example from the "Description", the case argument is the C string "foo bar" and the pattern is the C string "\\f\\o\\o\\ \\ \\b\\a\\r" that yields in the string: \f\o\o\ \ \b\a\r gmatch("foo bar", "\\f\\o\\o\\ \\ \\b\\a\\r") gives a match. If this did not result in a match, quotes in the pattern would be removed and strcmp() called with the "case" argument and the pattern with it's quoting removed. This results in a call to: strcmp("foo bar", "foo bar") that also gives a match. The additional strcmp() is important for patterns that do e.g. contain an illegal pattern like "[]foo".

(0004219) kre (reporter) 2019-01-23 06:04	Re note 3970 first... The strcmp() alternative to pattern matching is just plain crazy, and should in no way be endorsed. At the most it might be said that it is unspecified whether that happens (because those broken shells do it, apparently). The final sentence is irrelevant as there is no such thing as an "illegal pattern" every sting can be considered as a pattern, and they all match something. The example given is simply a string or ordinary chars (no meta chars appear - the '[' is not as there's no suitable ']' to cause it to be) so for that example there is certainly no need for a strcmp() to enable matching, regular glob matching will work for that one. Where strcmp() does make a difference, is for a case like case "a[b]c" in ( a[b]c ) echo BUG;; esac and when it happens (ie: matches), it is never what the script writer intended - in that case, if they had intended to match literal a literal [ they would have quoted it. Re note 3948... The "If quote removal" stuff should just be deleted, quote removal should never be performed on patterns before they are used. There is no point. Rather the second bullet item just needs to have its "if" precondition removed (and it woudl no longer need to be a bullet item.)

(0004311) geoffclare (manager) 2019-03-12 10:10	Re Note: 0004219 (last part), the "If quote removal" stuff cannot simply be deleted. There are two possibilities regarding quote removal and "case": either quote removal is performed before pattern matching, or quote removal is not performed at all. (It would be nonsensical to say it is done after pattern matching, because once pattern matching has been done there is nothing more that the word will be used for.) So neither of these cases fits the second bullet item, as it talks about "the quote characters that will be removed when quote removal is performed". I worded the first bullet item as "If quote removal ... has already been performed" because that matches the proposed new description of "case" in Note: 0002885.

(0004315) kre (reporter) 2019-03-12 12:39	Re Note 4311 (this part of this discussion does belong here...) You're right about the two possibilities wrt quote removal and case patterns - but the answer is clearly (should be clearly) "is not performed at all". That's the way the text in the std reads now - and what this bug was intended to change. There never was a need, the standard in this area was correct before. But the bug report is misconceived, patterns always match before quote removal happens, that's the way they work in pathname expansion and the way they work in substring matching in parameter expansion. There is no reason at all for pattern matching to be different, and every conceivable reason to keep it the same - it means that the same rules apply for pattern matching in all cases (other than the special cases for / and leading . in pathname expansion). This issue should simply be rejected as misconceived. All the rest of the work that has been done here on how pattern matching works should be moved elsewhere - either that or the subject of this issue should be changed to have nothing whatever to do with quote removal on case patterns. When one of those happens, the descriptions of how pattern matching works can be simplified, as we simply have quoted and not quoted, plus unquoted backslash characters to deal with, none of this "characters that were quoted" or whatever, which would be absurdly difficult to specify in any way that was both correct, and understandable.

(0004562) shware_systems (reporter) 2019-09-23 15:36 edited on: 2019-09-23 15:40	After the 2019-09-23 call, new interpretation is: Interpretation response ------------------------ Regarding parameter expansions ${var:-word}, ${var:=word}, etc., 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. Regarding case statement patterns, the standard clearly states how quoting affects pattern matching in case statements, and conforming implementations must conform to this. Rationale: ------------- Omitting quote removal from the expansions listed for the word in ${var:-word}, ${var:=word}, etc. is an oversight; it is believed that all implementations perform quote removal, as intended. It is clear in XCU section 2.13.1 that the characters '?', '' and '[' are only special in pattern matching when unquoted and not inside a bracket expression. Once the matching operation has been performed, it is irrelevant whether quote removal is then performed since the pattern is not used for anything further after that point. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- On page 2354 line 75061 section 2.6.2 Parameter Expansion, change: word* shall be subjected to tilde expansion, parameter expansion, command substitution, and arithmetic expansion to: word shall be subjected to tilde expansion, parameter expansion, command substitution, arithmetic expansion, and quote removal On page 2383 line 76227 section 2.13.1 Patterns Matching a Single Character, change: If an open bracket introduces a bracket expression as in XBD Section 9.3.5, except that the <exclamation-mark> character ('!') shall replace the <circumflex> character ('ˆ') in its role in a non-matching list in the regular expression notation, it shall introduce a pattern bracket expression. A bracket expression starting with an unquoted <circumflex> character produces unspecified results. Otherwise, '[' shall match the character itself. to: A <left-square-bracket> shall introduce a bracket expression if the characters following it meet the requirements for bracket expressions stated in [xref to XBD Section 9.3.5], except that the <exclamation-mark> character (<tt>’!’</tt>) shall replace the <circumflex> character (<tt>’ˆ’</tt>) in its role in a non-matching list in the regular expression notation. A bracket expression starting with an unquoted <circumflex> character produces unspecified results. A <left-square-bracket> that does not introduce a valid bracket expression shall match the character itself. 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), if performed, shall always be performed last.

(0004565) shware_systems (reporter) 2019-09-23 15:42 edited on: 2019-09-23 15:54	The majority of issues handled by Note 2885 are now incorporated into the resolution to Bug 1234, which is why the proposed interpretation of Note 4562 is significantly shorter.

(0004566) agadmin (administrator) 2019-09-24 08:53	Interpretation proposed 23 Sep 2019

(0004633) agadmin (administrator) 2019-10-29 10:34	Interpretation approved: 29 October 2019

Issue History
Date Modified	Username	Field	Change
2015-09-17 19:22	rhansen	New Issue
2015-09-17 19:22	rhansen	Name	=> Richard hansen
2015-09-17 19:22	rhansen	Organization	=> BBN
2015-09-17 19:22	rhansen	Section	=> 2.6.2, 2.9.4.3
2015-09-17 19:22	rhansen	Page Number	=> 2328, 2345
2015-09-17 19:22	rhansen	Line Number	=> 73944-73945, 74602-74603
2015-09-17 19:22	rhansen	Interp Status	=> ---
2015-09-17 19:23	rhansen	Desired Action Updated
2015-09-17 19:24	rhansen	Desired Action Updated
2015-09-18 08:34	geoffclare	Relationship added	related to 0000221
2015-09-18 08:39	geoffclare	Note Added: 0002835
2015-09-18 20:08	shware_systems	Note Added: 0002839
2015-09-18 20:18	shware_systems	Note Edited: 0002839
2015-10-01 18:29	rhansen	Note Added: 0002852
2015-10-02 08:45	geoffclare	Note Added: 0002853
2015-10-02 17:13	rhansen	Note Added: 0002855
2015-10-03 00:57	shware_systems	Note Added: 0002856
2015-10-04 07:52	geoffclare	Note Added: 0002858
2015-10-08 16:14	rhansen	Note Added: 0002863
2015-10-08 16:31	rhansen	Note Added: 0002864
2015-10-08 16:40	geoffclare	Note Added: 0002865
2015-10-08 16:41	rhansen	Relationship added	related to 0000249
2015-10-08 20:39	shware_systems	Note Added: 0002866
2015-10-15 15:55	geoffclare	Note Edited: 0002863
2015-10-15 15:56	geoffclare	Note Edited: 0002865
2015-10-15 15:59	geoffclare	Note Added: 0002876
2015-10-15 16:00	geoffclare	Interp Status	--- => Pending
2015-10-15 16:00	geoffclare	Final Accepted Text	=> bugnote:2876
2015-10-15 16:00	geoffclare	Status	New => Interpretation Required
2015-10-15 16:00	geoffclare	Resolution	Open => Accepted As Marked
2015-10-15 16:01	geoffclare	Tag Attached: tc3-2008
2015-11-05 17:09	rhansen	Final Accepted Text	bugnote:2876 =>
2015-11-05 17:09	rhansen	Note Added: 0002884
2015-11-05 17:09	rhansen	Status	Interpretation Required => New
2015-11-05 17:09	rhansen	Resolution	Accepted As Marked => Open
2015-11-05 17:17	rhansen	Note Added: 0002885
2015-11-05 17:21	rhansen	Note Edited: 0002885
2015-11-05 17:22	geoffclare	Note Deleted: 0002876
2015-11-05 17:23	geoffclare	Final Accepted Text	=> Note: 0002885
2015-11-05 17:23	geoffclare	Status	New => Interpretation Required
2015-11-05 17:23	geoffclare	Resolution	Open => Accepted As Marked
2016-12-15 18:11	ajosey	Interp Status	Pending => Proposed
2016-12-15 18:11	ajosey	Note Added: 0003522
2017-01-18 15:24	ajosey	Interp Status	Proposed => Approved
2017-01-18 15:24	ajosey	Note Added: 0003550
2018-04-11 15:54	geoffclare	Note Added: 0003947
2018-04-11 15:54	geoffclare	Status	Interpretation Required => Under Review
2018-04-11 15:54	geoffclare	Resolution	Accepted As Marked => Reopened
2018-04-12 08:11	geoffclare	Note Added: 0003948
2018-04-17 13:46	joerg	Note Added: 0003970
2018-04-17 13:47	joerg	Note Edited: 0003970
2018-04-17 13:50	joerg	Note Edited: 0003970
2018-04-17 13:50	joerg	Note Edited: 0003970
2019-01-23 06:04	kre	Note Added: 0004219
2019-03-04 16:50	eblake	Relationship added	related to 0001190
2019-03-12 10:10	geoffclare	Note Added: 0004311
2019-03-12 12:39	kre	Note Added: 0004315
2019-09-23 15:36	shware_systems	Note Added: 0004562
2019-09-23 15:37	shware_systems	Note Edited: 0004562
2019-09-23 15:38	Don Cragun	Final Accepted Text	Note: 0002885 => See Note: 0004562.
2019-09-23 15:38	Don Cragun	Status	Under Review => Interpretation Required
2019-09-23 15:38	Don Cragun	Resolution	Reopened => Accepted As Marked
2019-09-23 15:38	shware_systems	Note Edited: 0004562
2019-09-23 15:39	Don Cragun	Interp Status	Approved => Pending
2019-09-23 15:40	Don Cragun	Note Edited: 0004562
2019-09-23 15:42	shware_systems	Note Added: 0004565
2019-09-23 15:44	Don Cragun	Relationship added	related to 0001234
2019-09-23 15:50	geoffclare	Note Edited: 0002885
2019-09-23 15:54	shware_systems	Note Edited: 0004565
2019-09-24 08:53	agadmin	Interp Status	Pending => Proposed
2019-09-24 08:53	agadmin	Note Added: 0004566
2019-10-29 10:34	agadmin	Interp Status	Proposed => Approved
2019-10-29 10:34	agadmin	Note Added: 0004633
2019-11-28 12:08	geoffclare	Status	Interpretation Required => Applied
2022-01-17 10:34	geoffclare	Relationship added	has duplicate 0001552
2024-06-11 09:02	agadmin	Status	Applied => Closed

Aardvark Mark IV