WG15 Defect Report Ref: 9945-2-56
Topic: substitute


This is an approved interpretation of 9945-2:1993.

.

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			bostic@cs.berkeley.edu)

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.

 _____________________________________________________________________________