View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00011301003.1(2016/18)/Issue7+TC2Shell and Utilitiespublic2017-03-21 17:072024-06-11 09:09
ReporterAntonio Diaz Assigned To 
PrioritynormalSeverityObjectionTypeError
Status ClosedResolutionAccepted As Marked 
NameAntonio Diaz
OrganizationGNU
User Reference
Sectioned
Page Number2682
Line Number87448-87449
Interp Status---
Final Accepted TextSee 0001130:0004105
Summary0001130: Address 0 does not make sense for the c command
DescriptionThe synopsis of the c command states that "Address 0 shall be valid for this command; it shall be interpreted as if address 1 were specified".

The RATIONALE of the ed utility states that "For consistency with the a and r commands and better user functionality, the i and c commands must also accept an address of 0, in which case 0i is treated as 1i and likewise for the c command".

But accepting 0 as a valid address for the c command does not make sense because the c command executes a d command, which does not admit an address of 0. With respect to addresses, the c command should be treated as the d command, not as the a, i or r commands, because a, i and r do not delete anything.
See discussion at http://lists.gnu.org/archive/html/bug-ed/2016-04/msg00009.html
Desired ActionRemove from the synopsis of the c command and from the RATIONALE the requirement that the c command must accept address 0.
Tagstc3-2008

Relationships

related to 0001131 Closed The synopsis of the i command is wrong and inconsistent with the synopsis of the a command 

Activities

geoffclare

2018-08-31 14:16

manager   bugnote:0004098

I did some digging into the history...

This requirement was not in the original POSIX.2-1992. It came into the standard via the .2b amendment. Unfortunately .2b does not give a clear explanation for the change. It specifies this change followed by a change to the Global command, and then says "The preceding two changes are the result of interpretation request PASC 1003.2-92 #119 submitted for IEEE Std 1003.2-1992." Interpretation #119 can be found in this online zip file:

http://standards.ieee.org/findstds/interps/1003.2-1992_interp.zip

but it is entirely about the Global command; there is no mention of the Change command. Presumably the update to the Change command arose when discussion of interpretation #119 digressed, but it is a shame that the .2b developers did not capture the reason for the change as rationale in .2b.

I wonder whether they were considering ranges - it makes sense for 0,2c to work the same as 1,2c - however I agree with Antonio that specifying 0c to be the same as 1c makes no sense. The only behaviour for 0c that makes sense to me would be for it to work like 0a, by analogy with s/^/string/ which inserts the string at the beginning of a line.

Since most ed implementations changed to support address 0 in order to conform to .2b, I suggest that rather than removing the requirement, we should make support for address 0 optional and say that if it is supported, the behaviour is unspecified.

nick

2018-09-06 16:36

manager   bugnote:0004105

Suggested change: On page 2682, line 87448, delete "Address 0 shall be valid for this command; it shall be interpreted as if address 1 were specified."
On page 2691, lines 87803-87805, change

For consistency with the a and r commands and better user functionality, the i and c commands must also accept an address of 0, in which case 0i is treated as 1i and likewise for the c command.

to

For consistency with the a and r commands and better user functionality, the i command also accepts an address of 0. However, it is unspecified if <tt>0i</tt> is treated as <tt>1i</tt> (which will fail if the buffer is empty), or means insert at the beginning of the buffer (which will succeed even if the buffer is empty). Earlier versions of this standard required address 0 for the c command to be treated as 1 also, but this requirement has been removed, though implementations are permitted to do this as an extension.

nick

2018-09-06 16:43

manager   bugnote:0004107

Last edited: 2018-09-06 16:43

 Note that the resolution in 0001130:0004105 includes rationale for the change in 0001131

Issue History

Date Modified Username Field Change
2017-03-21 17:07 Antonio Diaz New Issue
2017-03-21 17:07 Antonio Diaz Name => Antonio Diaz
2017-03-21 17:07 Antonio Diaz Organization => GNU
2017-03-21 17:07 Antonio Diaz Section => ed
2017-03-21 17:07 Antonio Diaz Page Number => 0
2017-03-21 17:07 Antonio Diaz Line Number => 0
2018-08-30 16:24 nick Page Number 0 => 2682
2018-08-30 16:24 nick Line Number 0 => 87448-87449
2018-08-30 16:24 nick Interp Status => ---
2018-08-31 14:16 geoffclare Note Added: 0004098
2018-09-06 16:33 geoffclare Relationship added related to 0001131
2018-09-06 16:36 nick Note Added: 0004105
2018-09-06 16:37 nick Final Accepted Text => See Bugnote:0004105
2018-09-06 16:37 nick Status New => Resolution Proposed
2018-09-06 16:37 nick Resolution Open => Accepted As Marked
2018-09-06 16:37 nick Tag Attached: tc3-2008
2018-09-06 16:38 nick Status Resolution Proposed => Resolved
2018-09-06 16:43 nick Note Added: 0004107
2018-09-06 16:43 nick Note Edited: 0004107
2018-09-07 08:17 geoffclare Final Accepted Text See Bugnote:0004105 => See 0001130:0004105
2019-10-31 11:39 geoffclare Status Resolved => Applied
2024-06-11 09:09 agadmin Status Applied => Closed