Anonymous | Login | 2024-12-12 17:45 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0000985 | [1003.1(2013)/Issue7+TC1] Shell and Utilities | Objection | Omission | 2015-09-17 19:22 | 2024-06-11 09:02 | ||
Reporter | rhansen | View Status | public | ||||
Assigned To | |||||||
Priority | normal | Resolution | Accepted As Marked | ||||
Status | Closed | ||||||
Name | Richard hansen | ||||||
Organization | BBN | ||||||
User Reference | |||||||
Section | 2.6.2, 2.9.4.3 | ||||||
Page Number | 2328, 2345 | ||||||
Line Number | 73944-73945, 74602-74603 | ||||||
Interp Status | Approved | ||||||
Final Accepted Text | See Note: 0004562. | ||||||
Summary | 0000985: quote removal missing from case statement patterns and alternative expansions | ||||||
Description |
The specification for ${var:-word}, ${var:=word}, etc. does not say that quote removal is performed on word. However, in bash, ksh, and dash (at least), quote removal is performed:$ printf %s\\n ${isnotset-"foo bar"} foo bar Similarly, the specification for case statement patterns does not say that quote removal is performed on the pattern, yet in bash, ksh, and dash: $ case 'foo bar' in "foo bar") echo "quotes removed";; esac quotes removed |
||||||
Desired Action |
On page 2328 lines 73942-73945 (XCU 2.6.2 Parameter Expansion), change:In each case that a value of word is needed (based on the state of parameter, as described below), word shall be subjected to tilde expansion, parameter expansion, command substitution, and arithmetic expansion. to: In each case that a value of word is needed (based on the state of parameter, as described below), word shall be subjected to tilde expansion, parameter expansion, command substitution, arithmetic expansion, and quote removal. 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. |
||||||
Tags | tc3-2008 | ||||||
Attached Files | |||||||
|
Relationships | |||||||||||||||||||||||||||||||
|
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:
|
(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. 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 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 Characterto: Patterns Matching a Single Character 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 |
(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 |
(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 |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |