View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001804 | Issue 8 drafts | Shell and Utilities | public | 2024-01-27 04:47 | 2024-03-01 09:44 |
| Reporter | calestyo | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Resolved | Resolution | Accepted As Marked | ||
| Product Version | Draft 4 | ||||
| Name | Christoph Anton Mitterer | ||||
| Organization | |||||
| User Reference | |||||
| Section | sed | ||||
| Page Number | 3356, ff. | ||||
| Line Number | 114143, ff. | ||||
| Final Accepted Text | 0001804:0006694 | ||||
| Summary | 0001804: still some minor clarifications in the sed RE description | ||||
| Description | Hey. Not sure whether we had that already when we revised the sed description, at least I couldn't find that particular point being mentioned and rejected. | ||||
| Desired Action | Lines 114143-114145 say: > The escape sequence '\n' shall match a <newline> embedded in > the pattern space. A literal <newline> shall not be used in > the RE of a context address or in the substitute function. 1) First and nitpicking, the "substitute function" is IMO not really defined (in the sense that something says it means the s command). Most places in the text simply use the letter of the command and "command", so maybe we should do that here, too. 2) The sentence "A literal <newline> shall not be used in the RE of a context address or in the substitute function." is IMO wrong: I would interpret it as: > A literal <newline> shall not be used in > - the RE of a context address > - in the substitute function The first part is correct, but, the second part "not … in the substitute function)" is AFAIU only half the truth respectively amgiuous: - it must not be used in the RE part of a s-command - but may be used in the replacement part of that (see line 114277, ff.) I'd clarify that by something like: > A literal <newline> shall not be used in the RE of a context > address or s command. or better: > A literal <newline> shall not be used in the RE of a context > address or that of a s command. or: > A literal <newline> shall not be used in the RE of a context > address or the RE of a s command. 3) Should there be any wording about whether a literal <newline> is allowed in the y command? The description of y itself doesn't say that, but it says that <backslash>n is taken as <newline>, so I'd be tempted to assume that a literal <newline> is not allowed in it. 4) Speaking of which, in line 114143 the text uses the wording "escape sequence '\n'", whereas in 114309 it uses "a <backslash> followed by an 'n'". Cosmetically, that should maybe be aligned (with me personally preferring the former form). Thanks, Chris | ||||
| Tags | tc1-2024 | ||||
|
|
At page 3356 lines 114143 - 114145 change:The escape sequence '\n' shall match a <newline> embedded in the pattern space. A literal <newline> shall not be used in the RE of a context address or in the substitute function. to: The escape sequence <backslash> followed by an 'n' shall match a <newline> embedded in the pattern space. The application shall ensure that an escaped literal <newline> is not used in the RE of a context address or the RE of an s command. At page 3360 line 114308 - 114320 change: Replace all occurrences of characters in string1 with the corresponding characters in string2. If a <backslash> followed by an 'n' appear in string1 or string2, the two characters shall be handled as a single <newline>. If (after resolving any escape sequences) the numbers of characters in string1 and string2 are not equal, or if any of the characters in string1 appear more than once, the results are undefined. Any character other than <backslash> or <newline> can be used instead of <slash> to delimit the strings. If the delimiter is not 'n', within string1 and string2, 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. The meaning of an unescaped <backslash> followed by any character that is not 'n', a <backslash>, or the delimiter character is undefined. to: Replace all occurrences of characters in string1 with the corresponding characters in string2. Any character other than <backslash> or <newline> can be used instead of <slash> to delimit the strings. If the delimiter is not 'n', within string1 and string2, 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 a preceding unescaped <backslash> character in string1 or string2, the two <backslash> characters shall represent a single literal <backslash> character. If an 'n' character is escaped by a preceding unescaped <backslash> character in string1 or string2, the two characters shall represent a single literal <newline>. The meaning of an unescaped <backslash> followed by any character that is not 'n', a <backslash>, or the delimiter character is undefined. If (after resolving any escape sequences) the numbers of characters in string1 and string2 are not equal, or if any of the characters in string1 appear more than once, the results are undefined. |
|
|
Looks good to me. I assume it's by intention that in your changes to the y command there's no direct mentioning of whether a literal <newline> is allowed (my original point (3))? I mean from "Any character other than <backslash> or <newline> can be used instead of <slash> to delimit the strings." one can already deduce that <newline> is a character and from "Replace all occurrences of characters in string1 with the corresponding characters in string2." one could then follow that is should therefore be allowed. It may just be confusing that then there's still the <backslash>n escape sequence (in addition). |
|
|
> I assume it's by intention that in your changes to the y command there's no direct mentioning of whether a literal <newline> is allowed (my original point (3))? Yes. The existing text covers an escaped <newline> (last sentence in old text, penultimate in new). An unescaped <newline> terminates the command (causing a syntax error if it is before the final delimiter). We tweaked the RE wording at line 114143 to match by inserting "escaped" before "literal <newline>". |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-01-27 04:47 | calestyo | New Issue | |
| 2024-01-27 04:47 | calestyo | Name | => Christoph Anton Mitterer |
| 2024-01-27 04:47 | calestyo | Section | => sed |
| 2024-01-27 04:47 | calestyo | Page Number | => 3356, ff. |
| 2024-01-27 04:47 | calestyo | Line Number | => 114143, ff. |
| 2024-02-29 16:59 | geoffclare | Note Added: 0006694 | |
| 2024-02-29 17:00 | geoffclare | Final Accepted Text | => 0001804:0006694 |
| 2024-02-29 17:00 | geoffclare | Status | New => Resolved |
| 2024-02-29 17:00 | geoffclare | Resolution | Open => Accepted As Marked |
| 2024-02-29 17:01 | geoffclare | Tag Attached: tc1-2024 | |
| 2024-02-29 20:36 | calestyo | Note Added: 0006696 | |
| 2024-03-01 09:44 | geoffclare | Note Added: 0006697 |
