.
Last update: 1997-05-20
9945-2-56 _____________________________________________________________________________ Topic: substitute Relevant Sections: 5.10.7.2.30 Defect Report: ----------------------- Reference: Page 536, Section 5.10.7.2.30, "substitute" There are things in the specification of the ex/vi substitute command in 9945-2:1993 that I believe differ from historic practice. 1: There is no wording which limits the option characters that are accepted by implementations. Historically, the options were limited to 'c', 'g' and 'r'. 2: Historic implementations accepted the 'r' option as well as the 'c' and 'g' options. The effect of the 'r' option was to cause the use of the last BRE used in any command, the same as the '~' command. 3: Historically, the 'c' and 'g' options were toggled, e.g. the command ":s/abc/def/" was the same as "s/abc/def/ccccgggg". 4: Historically, any substitute could be interrupted by SIGINT, not just those having the 'c' option. 5: I don't believe that the substitute command was historically affected by the wrapscan option. 6: The historic edcompatible option is missing from the standard. The behavior of the edcompatible option was that it made the values of the 'c' and 'g' suffices remembered instead of being reinitialized to "off" for each substitute command. The single special case was that they were always reinitialized to 0 if the pattern and replacement strings were specified. Was it the intent of the POSIX 9945-2 standard to change historic practice in these ways? One other comment. The current wording of 5.10.7.2.30 requires vi mode to implement the historic practice of displaying the line with '^' characters under it, something that is incredibly inefficient and baroque given the capabilities of current terminals. It would be nice to permit superior vi implementations that, for example, highlighted the characters to be substituted instead of redisplaying the line and destroying the screen presentation. (There are at least two implementations of vi that have this capability.) (Keith Bostic [email protected]) WG15 response for 9945-2:1993 ----------------------------------- Q1 and Q2: The standard clearly states behavior for the 'c' and 'g' options, and conforming implementations must conform to this. For the 'r' option the standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. The 'c' and 'g' are only the minimum requirements, implemenations may provide additional facilities. This is being referred to the sponsor. Q3: The standard states behavior for the 'c' and 'g' options, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Q4: The standard states behavior for the 'c' option and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Q5: The standard states the behavior for the interaction with the wrapscan option, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor. Q6: The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Paragraph #10: The request is substantially identical to interpretation #63, and the resolution of that interpretation applies in this case. Rationale for Interpretation: ----------------------------- None. _____________________________________________________________________________