Anonymous | Login | 2024-11-03 19:14 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 | ||
0001550 | [Issue 8 drafts] Shell and Utilities | Editorial | Enhancement Request | 2022-01-14 05:32 | 2024-06-11 09:12 | ||
Reporter | calestyo | View Status | public | ||||
Assigned To | |||||||
Priority | normal | Resolution | Accepted As Marked | ||||
Status | Closed | Product Version | Draft 2.1 | ||||
Name | Christoph Anton Mitterer | ||||||
Organization | |||||||
User Reference | |||||||
Section | Utilities, sed | ||||||
Page Number | 3132, ff. (in the draft) | ||||||
Line Number | see below | ||||||
Final Accepted Text | Note: 0005816 | ||||||
Summary | 0001550: clarifications/ambiguities in the description of context addresses and their delimiters for sed | ||||||
Description |
Hey. First of all, I've asked/reported all his already at the mailing list: "sed and delimiters that are also special characters to REs" https://collaboration.opengroup.org/austin/plato/protected/mailarch.php?soph=N&action=show&archive=austin-group-l&num=33587&limit=100&offset=0&sid= [^] (unfortunately there seems to be no thread-view) I was looking into using BREs/EREs within delimiters, which as far as POSIX is concerned should be only sed, and in: - context addresses (e.g. /RE/ or \xREx with x being another delimiter, of which the 1st needs to be quoted if not / ) - s-command - y-command For simplicity, this ticket covers only proposals with respect to the context addresses. 1) In the chapter "Addresses in sed": »which consists of an RE, as described in Regular Expressions in sed, preceded and followed by a delimiter, usually a <slash>« (106070 et seq., draft PDF) I would append something like: "but see <chapter:Regular Expressions in sed> for details when other delimiters shall be used" The motivation is, that if one reads this part alone, one might easily think that any other character could be used, but: - any other character than / requires the first delimiter to be quoted with a \ - not all other characters are allowed as delimiter (namely \ and newline are not) 2) In the chapter "Regular Expressions in sed" (106070, draft PDF): »In a context address, the construction "\cREc", where c is any character other than <backslash> or <newline>, shall be identical to "/RE/". If the character designated by c appears following a <backslash>, then it shall be considered to be that literal character, which shall not terminate the RE.« (106087 et seq., draft PDF) a) After »shall be identical to "/RE/"« I'd add a clarification like: "(that is: when a delimiter other than <slash> is used it's first occurrence)" Simply to make that rather cryptic text a bit easier to understand. b) It should further be added (the answer to which I don't know), whether or not the first delimiter may also be quoted if a slash is used, i.e. whether \/RE/ is equal to /RE/ (which the first sentence would imply. c) The sentence: »If the character designated by c appears following a <backslash>, then it shall be considered to be that literal character, which shall not terminate the RE.« seems IMO ambiguous or wrong: AFAIU, it is however every \c *AFTER the first delimiter* (that is after the first \c), that is taken literally. One might even think about moving that whole paragraph (i.e. the fist bullet point) up into "Addresses in sed",... cause that rather explains the context addresses and the quoting of their delimiter, when it's used inside the context address (which is admittedly an RE, but still). |
||||||
Desired Action |
see above, clarify things and resolve ambiguities Thanks, Chris. |
||||||
Tags | issue8 | ||||||
Attached Files | |||||||
|
Relationships | |||||||||||||||||||||
|
Notes | |
(0005601) calestyo (reporter) 2022-01-14 05:40 |
https://www.austingroupbugs.net/view.php?id=1551 [^] may be a bit related to all this |
(0005603) Don Cragun (manager) 2022-01-14 06:54 |
This was originally filed against the Issue 7 + TC2 project, but the page and line numbers are from Issue 8 draft 2.1. It has been moved to the Issue 8 project. |
(0005756) geoffclare (manager) 2022-03-18 11:15 edited on: 2022-03-18 11:15 |
Taking the points raised in turn: 1) Since there is already a cross-reference to "Regular Expressions in sed", rather than adding a second in the same sentence, I would rearrange the sentence, e.g.: ... (which consists of an RE, preceded and followed by a delimiter—usually a <slash>—as described in Regular Expressions in sed). 2a) I would put the reason for the construction up front instead of later: In a context address, a delimiter other than <slash> can be used by means of the construction ...I also think "shall be identical" is wrong because that implies that <slash> still needs to be escaped in the RE even if "c" is a different character. 2b) It is already perfectly clear that "c" can be any character other than <backslash> or <newline>. Which means it can be <slash>. No change needed. 2c) By a strict reading, you are right, although I think the intention is clear. Any fix for this would overlap with bug 0001551 so is probably best addressed there. I agree with the final comment about moving that bullet item. The need to escape the delimiter is described in the s and y commands, not here, so it seems odd that it is here for context addresses instead of in the description of addresses. |
(0005761) geoffclare (manager) 2022-03-25 16:18 edited on: 2022-03-25 16:22 |
Proposed changes to fix this bug and bug 0001551 (I was unable to disentangle the changes into two clean separate edits): On page 3134 line 106070 section sed, after: ... preceded and followed by a delimiter, usually a <slash>).add a new paragraph: In a context address, any character other than <backslash> or <newline> can be specified for use as the delimiter by means of the construction "\cREc", where c is the chosen delimiter character. The BRE and ERE syntax shall additionally support escaping occurrences of the delimiter within the RE with an unescaped <backslash> (except inside a bracket expression). If the character designated by c is not special in a BRE or ERE according to [xref to XBD 9.3] or [xref to XBD 9.4], respectively, the escape sequence <backslash>c shall be treated as that literal character; otherwise, it is unspecified whether the escape sequence <backslash>c is treated as the literal character or the special character. In either case, the escape sequence <backslash>c shall not terminate the RE. For example, the context address "\xabc\xdefx" is equivalent to "/abcxdef/". On page 3134 line 106087 section sed, replace the first bullet item (beginning "In a context address") with: The delimiter character that precedes and follows the RE shall not terminate the RE when it appears within a bracket expression. For example, the context address "/[/]/" is equivalent to "/\//". On page 3137 line 106204 section sed (s command), change: Within the RE and the replacement, the RE delimiter itself can be used as a literal character if it is preceded by a <backslash>.to: Within the RE and the replacement, the delimiter shall not terminate the RE or replacement if it is preceded by an unescaped <backslash> (that is not inside a bracket expression in the RE, where the delimiter does not terminate the RE anyway - see [xref to Regular Expressions in sed]). If the delimiter character is not special in a BRE or ERE according to [xref to XBD 9.3] or [xref to XBD 9.4], respectively, the escape sequence <backslash>delimiter shall be treated as that literal character in the RE; otherwise, it is unspecified whether the escape sequence <backslash>delimiter is treated as the literal character or the special character. Likewise, if the delimiter character is not <ampersand> ('&'), the escape sequence <backslash>delimiter shall be treated as that literal character in the replacement; if it is <ampersand>, it is unspecified whether the escape sequence <backslash>delimiter is treated as the literal character or the special character (see below). On page 3138 line 106253 section sed (y command), change: ... the delimiter itself can be used as a literal character if it is preceded by a <backslash>. If a <backslash> character is immediately followed by a <backslash> character in string1 or string2, the two <backslash> characters shall be counted as a single literal <backslash> character.to: ... the delimiter itself can be used as a literal character if it is preceded by an unescaped <backslash>. If a <backslash> character is escaped by an immediately preceding unescaped <backslash> character in string1 or string2, the two <backslash> characters shall be treated as a single literal <backslash> character. On page 3138 line 106278 section sed, add a new paragraph to APPLICATION USAGE: Applications that use a special RE character as a delimiter (for example, '.' or '*') and need to use the delimiter as a literal character in the RE should put it inside a bracket expression, as implementations differ regarding whether escaping it with a <backslash> removes its special meaning. On page 3140 line 106354 section sed, add a new paragraph to RATIONALE: Some historical sed implementations did not support escaping '(', ')', '{', and '}' when used as a BRE delimiter, as the sequences "\(" and so on were still treated as special, usually resulting in an error. This standard requires that these sequences are treated as the literal character. This is for consistency with extensions. For example, some implementations treat "\s" in a BRE as matching white-space characters, as an extension. This cannot have its special meaning when 's' is used as a BRE delimiter in order to ensure portability of sed commands that have 's' as a delimiter and escape it. If "\s" were allowed to keep its special meaning, then the potential for further extensions would mean portable applications would not be able to escape any delimiter character other than <slash>. |
(0005767) calestyo (reporter) 2022-03-26 00:08 edited on: 2022-03-26 00:34 |
Re: https://austingroupbugs.net/view.php?id=1550#c5756 [^] your (1): agreed your (2a): agreed, and you're right about the issue with "shall be identical" your (2b): I wouldn't agree here because... In "where c is any character other than <backslash> or <newline>", the idea behind exclusion of <backslash> and <newline> is, AFAIU, rather a *general* exclusion, that is in the sense of "neither of these two characters can ever be delimiters". I wouldn't have understood that sentence in the sense of "any c except <backslash> and <newline> have to use the \cREc form" but rather as "any c have to use the \cREc form and <backslash> or <newline> cannot be used at all". I agree, that the wording of the sentence actually describes the former,... but I think the spirit that it means is rather the latter (in which case it would be open whether c is any character or any character except (forward) <slash>). If not, the question would be open as to how <backslash> or <newline> would be encoded as delimiters. your (2c): Well I agree it's "semi-clear" (especially because of the given example)... still adding a short clarification as in: "If any but the first occurrence of the character designated by c appears following a <backslash>" shouldn't cause much harm and make it really definite. I personally would recommend against dealing with that in https://austingroupbugs.net/view.php?id=1551 [^] . While they touch the same section, this one here is merely a subtle cosmetic change, which doesn't really affect the deeper semantics as most of #1551 does. Reviewing https://austingroupbugs.net/view.php?id=1550#c5761 [^] which you say also fixes #1551 will take me some time... it's quite difficult to read and cross check... especially since #1551 really contained quite a number of subtle issues. |
(0005771) calestyo (reporter) 2022-04-02 01:53 |
Okay I finally had a chance to look into https://austingroupbugs.net/view.php?id=1550#c5761: [^] I'll try to add to this ticket only those review parts of your proposal, that really affect this ticket... and everything else to the other tickets. I) Regarding your new paragraph "In a context address, any character…" a) I think this (its first sentence) basically fixes my original point (1) of this ticket. b) The whole paragraph does however add some mess to the subchapters: I know that it was me who suggested that originally (shame on me)... but now that I see it... it seems I was wrong (though I could live with it). Everything form it's 2nd sentence ("The BRE and ERE...") describes rather the behaviour of context address delimiters in REs, yet it's found in "Addresses in sed" rather than "Regular Expressions in sed". Similar content than in this paragraph, is found in the one you add to the s-command ("Within the RE and the replacement..."). So maybe, in "Addresses in sed" we should better *only* describe the \cREc form of these,... and link to "Regular Expressions in sed" for how delimiters are escaped? On could then also try to remove the respective parts from the s-command and unify both in "Regular Expressions in sed". The only difficulty is perhaps that for the s-command there's also the ambiguity with & in the replacement, that part should perhaps stay in the s-command. c) Also, right now (which may be on purpose, however)... \/RE/ would be allowed, and identical to /RE/. This is basically my original point (2b) d) Right now, it does not really seem to be specified, that / alone as delimiter needs not to be escaped in a context address, there's merely the "preceded and followed by a delimiter, usually a <slash>" left, but that alone could also mean that the \ needs to be added on the first / . (Ic), (Id) as well as my original (2b) would be fixed, if we'd write something like: "When the delimiter character c is <slash>, a context address \/RE/ can also be written as /RE/." (or something similar but better). That would make it clear that \/RE/ is allowed and identical to /RE/ and at the same time define /RE/. II) Regarding your removal/replacement of the first bullet item (beginning "In a context address") on page 3134 line 106087. - fixes my original points (2a) and (2c). - fixes the problem you found with "shall be identical" My previous notes in https://austingroupbugs.net/view.php?id=1550#c5767 [^] should now be all obsolete or I've mentioned them again in this post. Further comments to your proposed text in the other issues. Oh, and if you should change your proposed text,... could you please always make a new post, and perhaps add a version number or so? That way one can diff the a new version with an already "reviewed" one more easily, and also refer to it more easily. Thanks! |
(0005772) calestyo (reporter) 2022-04-02 02:30 |
What I write above in (1b) kinda also applies to the newly added paragraph in "Regular Expressions in sed": "The delimiter character that precedes..." and it's counterpart in the s-command: "Within the RE and the replacement, the delimiter shall not terminate" Conceptually they match the new sentence: "In either case, the escape sequence <backslash>c shall not terminate the RE. For example" in "Addresses in sed"... ... all describe, AFAIU, two things: - the delimiter character with a RE bracket expression is never used as a delimiter (and thus escaping it in the bracket expression, would actually not be escaping, but the literal \) and: - otherwise, a escaped delimiter (where the escaping \ is itself not escaped)... is not a delimiter (but something else... which depends on the character, BRE vs ERE,... and (what I hate:) the implementation) and both of these fro s-command AND context addresses. |
(0005775) kre (reporter) 2022-04-02 09:37 |
Rather than making the spec for delimiters ban the use of backslash or newline, I'd prefer to simply say "Any character ..." and leave the basic definition at that. Then, in a subsequent sentence, or perhaps even paragraph, say something like Note: even if escaped, the characters <backslash> and <newline> cannot be used as dellimiter characters. <backslash> does not work, as if unescaped later in the RE, it either becomes the escape character, in which case its purpose is to escape the following character, which can then never be the ending delimiter, or it forms part of a bracket expression, inside which the ending delimiter for the RE cannot be located. <newline> does not work either, as if not escaped, it is removed, and terminates the command, meaning it cannot be the ending delimiter., and if escaped, cannot be the ending delimiter either. Hence use of either of these characters as a delimiter makes it impossible to supply the required ending delimiter. That both removes the \ and \n from being odd special cases, and explains just why they don't (can't) work as delimiter characters (without requiring any extra text to explain what the implementation should do should the user attempt to do such a thing). |
(0005777) calestyo (reporter) 2022-04-02 19:47 |
That indented paragraph of yours (in Note 0005775) should (if at all) only go to the Rationale, IMO. At least the part which describes *why* <backslash> and <newline> cannot be used. Cause for the purpose of the standard itself it's not really relevant *why* they mustn't be used, but only *that* this is the case. Also, I'd rather really forbid their use, instead of just explaining why it wouldn't work anyway. Simply because otherwise an (crazy) implementation might try to "workaround" that limitation in some odd way, which again makes it non-portable. |
(0005790) geoffclare (manager) 2022-04-08 09:20 |
New proposed changes to fix this bug and bug 0001551 ... On page 3134 line 106070 section sed, after: ... preceded and followed by a delimiter, usually a <slash>).add a new paragraph: In a context address, any character other than <backslash> or <newline> can be specified for use as the delimiter by means of the construction "\cREc", where c is the chosen delimiter character. The BRE and ERE syntax shall additionally support escaping occurrences of the delimiter within the RE by means of an escape sequence (see [xref to XBD 9.1]). If the character designated by c is not special in a BRE (if the -E option is not specified) or ERE (if -E is specified) according to [xref to XBD 9.3.3] or [xref to XBD 9.4.3], respectively, the escape sequence <backslash>c shall be treated as that literal character; otherwise, it is unspecified whether the escape sequence <backslash>c is treated as the literal character or the special character. In either case, the escape sequence <backslash>c shall not terminate the RE. The construction "\cREc" does not need to be used when the delimiter is a <slash>; for example, the context address "\xabc\xdefx" is equivalent to "/abcxdef/". On page 3134 line 106087 section sed, replace the first bullet item (beginning "In a context address") with: The delimiter character that precedes and follows the RE shall not terminate the RE when it appears within a bracket expression, and shall have its normal meaning in the bracket expression. For example, the context address "/[/]/" is equivalent to "/\//", and the command "s-[0-9]--g" is equivalent to "s/[0-9]//g". On page 3137 line 106204 section sed (s command), change: Within the RE and the replacement, the RE delimiter itself can be used as a literal character if it is preceded by a <backslash>.to: Within the RE and the replacement, the delimiter shall not terminate the RE or replacement if it is the second character of an escape sequence (see [xref to XBD 9.1]). If the delimiter character is not special in a BRE (if the -E option is not specified) or ERE (if -E is specified) according to [xref to XBD 9.3.3] or [xref to XBD 9.4.3], respectively, the escaped delimiter shall be treated as that literal character in the RE; otherwise, it is unspecified whether the escaped delimiter is treated as the literal character or the special character. Likewise, if the delimiter character is not <ampersand> ('&'), the escaped delimiter shall be treated as that literal character in the replacement; if it is <ampersand>, it is unspecified whether the escaped delimiter is treated as the literal character or the special character (see below). On page 3138 line 106253 section sed (y command), change: ... the delimiter itself can be used as a literal character if it is preceded by a <backslash>. If a <backslash> character is immediately followed by a <backslash> character in string1 or string2, the two <backslash> characters shall be counted as a single literal <backslash> character.to: ... the delimiter itself can be used as a literal character if it is preceded by an unescaped <backslash>. If a <backslash> character is escaped by an immediately preceding unescaped <backslash> character in string1 or string2, the two <backslash> characters shall be treated as a single literal <backslash> character. On page 3138 line 106278 section sed, add a new paragraph to APPLICATION USAGE: Applications that use a special RE character as a delimiter (for example, '.' or '*') and need to use the delimiter as a literal character in the RE should put it inside a bracket expression, as implementations differ regarding whether escaping it with a <backslash> removes its special meaning. For example, the context address "\.[.][0-9]." is equivalent to "/\.[0-9]/"; however, with "\.\.[0-9]." it is unspecified which of "/\.[0-9]/" or "/.[0-9]/" is its equivalent form. On page 3140 line 106354 section sed, add two new paragraphs to RATIONALE: The characters <backslash> and <newline> cannot be used as RE delimiter characters (even in a context address using "\cREc"), as they can never be recognized as the ending delimiter: |
(0005809) calestyo (reporter) 2022-04-17 23:51 |
With respect to the proposal in #5790 and any open points in this issue as well as issues #1551 and #1556, I've replied to Geoff's longer mail on the austin-group-l@opengroup.org list. It contains some ideas for improvement (including some concrete ones like for better examples)... and also a list of those points that haven't been dealt with, yet, (the most important one IMO being the case of what '\n' is in 'snAAA\nnXXXn' - newline or escaped delimiter character). So may I kindly ask any participant in this ticket, to look there? |
(0005816) geoffclare (manager) 2022-04-22 08:29 |
Updated proposal following further discussion on the mailing list ... These changes are to fix this bug and also bugs 0001551 and 0001556. On page 3134 line 106070 section sed, change: or a context address (which consists of an RE, as described in [xref to Regular Expressions in sed], preceded and followed by a delimiter, usually a <slash>).to: or a context address. A context address has either the form "/RE/" or "\cREc", where RE is a regular expression as described in [xref to Regular Expressions in sed], and c is any character other than <backslash> or <newline>. In a sed context address, the BRE and ERE syntax shall be extended to support escaping occurrences of the <slash> or c delimiter within the RE by means of an escape sequence (see [xref to XBD 9.1]). For the "\cREc" form, if the character designated by c is not listed as a special BRE character (if the -E option is not specified) or a special ERE character (if -E is specified) in [xref to XBD 9.3.3] or [xref to XBD 9.4.3], respectively, the escape sequence <backslash>c shall be treated as that literal character; otherwise, it is unspecified whether the escape sequence <backslash>c is treated as the literal character or the special character. In either case, the escape sequence <backslash>c shall not terminate the RE. For example, in the context address "/abc\/def/", the second <slash> stands for itself, so that the RE is "abc/def", and in "\xabc\xdefx", the second 'x' stands for itself, so that the RE is "abcxdef". On page 3134 line 106085 section sed, change: Both BREs and EREs shall also support the following additionsto: In sed, the BRE and ERE syntax shall be extended as follows On page 3134 line 106087 section sed, replace the first bullet item (beginning "In a context address") with: The delimiter character that precedes and follows the RE shall not terminate the RE when it appears within a bracket expression, and shall have its normal meaning in the bracket expression. For example, the context address "\%[%]%" is equivalent to "/[%]/", and the command "s-[0-9]--g" is equivalent to "s/[0-9]//g". On page 3137 line 106204 section sed (s command), change: Within the RE and the replacement, the RE delimiter itself can be used as a literal character if it is preceded by a <backslash>.to: Within the RE (as a sed extension to the BRE and ERE syntax) and the replacement, the delimiter shall not terminate the RE or replacement if it is the second character of an escape sequence (see [xref to XBD 9.1]). If the delimiter character is not listed as a special BRE character (if the -E option is not specified) or a special ERE character (if -E is specified) in [xref to XBD 9.3.3] or [xref to XBD 9.4.3], respectively, the escaped delimiter shall be treated as that literal character in the RE; otherwise, it is unspecified whether the escaped delimiter is treated as the literal character or the special character. Likewise, if the delimiter character is not <ampersand> ('&'), the escaped delimiter shall be treated as that literal character in the replacement; if it is <ampersand>, it is unspecified whether the escaped delimiter is treated as the literal character or the special character (see below). On page 3137 line 106221 section sed (s command), change: A substitution shall be considered to have been performed even if the replacement string is identical to the string that it replaces. Any <backslash> used to alter the default meaning of a subsequent character shall be discarded from the RE or the replacement before evaluating the RE or using the replacement.to: Any <backslash> used to alter the default meaning of a subsequent character shall be discarded from the resulting replacement string. A substitution shall be considered to have been performed even if the resulting replacement string is identical to the string that it replaces. On page 3138 line 106253 section sed (y command), change: ... the delimiter itself can be used as a literal character if it is preceded by a <backslash>. If a <backslash> character is immediately followed by a <backslash> character in string1 or string2, the two <backslash> characters shall be counted as a single literal <backslash> character.to: ... the delimiter itself can be used as a literal character if it is preceded by an unescaped <backslash>. If a <backslash> character is escaped by an immediately preceding unescaped <backslash> character in string1 or string2, the two <backslash> characters shall be treated as a single literal <backslash> character. On page 3138 line 106278 section sed, add a new paragraph to APPLICATION USAGE: Applications that use a special RE character as a delimiter (for example, '.' or '*') and need to use the delimiter as a literal character in the RE should put it inside a bracket expression, as implementations differ regarding whether escaping it with a <backslash> removes its special meaning. For example, for the context address "/\.[0-9]/" to be written with '.' as delimiter, the form "\.[.][0-9]." needs to be used; "\.\.[0-9]." cannot be used portably for this purpose, as it is unspecified whether this would be equivalent to "/\.[0-9]/" or "/.[0-9]/". Portable applications cannot use a special RE character as a delimiter if that character needs to have its special meaning in the RE, as escaping it may remove its special meaning. On page 3140 line 106354 section sed, add two new paragraphs to RATIONALE: The characters <backslash> and <newline> cannot be used as RE delimiter characters, as they can never be recognized as the ending delimiter: |
Issue History | |||
Date Modified | Username | Field | Change |
2022-01-14 05:32 | calestyo | New Issue | |
2022-01-14 05:32 | calestyo | Name | => Christoph Anton Mitterer |
2022-01-14 05:32 | calestyo | Section | => Utilities, sed |
2022-01-14 05:32 | calestyo | Page Number | => 3132, ff. (in the draft) |
2022-01-14 05:32 | calestyo | Line Number | => see below |
2022-01-14 05:40 | calestyo | Note Added: 0005601 | |
2022-01-14 06:34 | Don Cragun | Relationship added | related to 0001551 |
2022-01-14 06:52 | Don Cragun | Project | 1003.1(2016/18)/Issue7+TC2 => Issue 8 drafts |
2022-01-14 06:54 | Don Cragun | Note Added: 0005603 | |
2022-01-14 06:54 | Don Cragun | version | => Draft 2.1 |
2022-03-18 11:15 | geoffclare | Note Added: 0005756 | |
2022-03-18 11:15 | geoffclare | Note Edited: 0005756 | |
2022-03-25 16:18 | geoffclare | Note Added: 0005761 | |
2022-03-25 16:22 | geoffclare | Note Edited: 0005761 | |
2022-03-26 00:08 | calestyo | Note Added: 0005767 | |
2022-03-26 00:34 | calestyo | Note Edited: 0005767 | |
2022-03-31 16:00 | nick | Relationship added | related to 0001556 |
2022-04-02 01:53 | calestyo | Note Added: 0005771 | |
2022-04-02 02:30 | calestyo | Note Added: 0005772 | |
2022-04-02 09:37 | kre | Note Added: 0005775 | |
2022-04-02 19:47 | calestyo | Note Added: 0005777 | |
2022-04-08 09:20 | geoffclare | Note Added: 0005790 | |
2022-04-17 23:51 | calestyo | Note Added: 0005809 | |
2022-04-22 08:29 | geoffclare | Note Added: 0005816 | |
2022-04-28 15:12 | geoffclare | Final Accepted Text | => Note: 0005816 |
2022-04-28 15:12 | geoffclare | Status | New => Resolved |
2022-04-28 15:12 | geoffclare | Resolution | Open => Accepted As Marked |
2022-04-28 15:13 | geoffclare | Tag Attached: issue8 | |
2022-05-05 15:00 | nick | Relationship added | related to 0001578 |
2022-05-26 10:34 | geoffclare | Status | Resolved => Applied |
2023-04-11 14:30 | geoffclare | Relationship added | related to 0001662 |
2024-06-11 09:12 | agadmin | Status | Applied => Closed |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |