Use of the information contained in this unapproved document is at your own risk
.Last update: 20 April,2001
1003.2-92 #56 _____________________________________________________________________________ Interpretation Number: XXXX Topic: substitute Relevant Sections: 5.10.7.2.30 Interpretation Request: (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 1003.2-1992 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 1003.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 bostic@cs.berkeley.edu) IEEE Interpretation for 1003.2-1992 ----------------------------------- 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. _____________________________________________________________________________