bug-ed
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-ed] Problems in POSIX description of ed reported


From: Andrew L. Moore
Subject: Re: [Bug-ed] Problems in POSIX description of ed reported
Date: Thu, 17 Aug 2017 11:11:22 -0400

Antonio Diaz writes:
> Andrew Moore wrote:
>> Your rationale for rejecting 0c is based on implementation details.
> No, it is not.

Antonio, to quote your rationale:

    … accepting 0 as a valid address for the c command does not
    make sense because the c command executes a d   command ...

That sounds a lot like implementation details to me. In any case,
I think we can agree that there is, in fact, no issue with implementing
the described behavior.

But let me try arguing your side for a moment:  Does the ed
command `0c’  mean `1c’ as POSIX states, or should it behave like
the command `0a’, which is valid even in an empty buffer?  Defining
it to be the equivalent of `0a’ is more consistent, one could say,
especially if we accept that `0i’ should behave this way as well.
But this ambiguity in interpreting the behavior of `0c’ is precisely why
it should not be valid.

Now let me take the naive user’s perspective: Since the command
`0a’ means “insert before the first line” then it seems reasonable to
expect the command `0i’ to also “insert before the first line”.  And
to be consistent with modal commands `a’ and `i’, address `0’
should be valid against command `c’ as well. But command `c’
changes an existing line, so it follows that `0c’ should “change the
first line."

The naive user’s argument leaves something to be desired, but I
believe the POSIX rationale is that, when possible, give the user the
benefit of the doubt.

>> By analogy, think of military time, where 24:00 is the same as 00:00
>> (i.e., midnight).
> 
> If this were true in ed, then '$+1' would be a synonym for 1. But in ed,
>  '$+1' is neither a valid address nor a synonym for anything.


Again, from the user’s perspective,  it’s not too much of a stretch to
suppose that 0 might inadvertently be used as a representation of
“the first line”.

> Address 0 represents a place "before the first line". It makes sense
> where a place is needed, for example a place where text will be
> appended. Commands like 'c', 'd' and' 'j' need real line addresses,
> because they operate on lines, not in places. The line "before the first
> line" can't be replaced, deleted or joined, because it does not exist.

POSIX singles out command `c’ because it’s one of the three modal
commands - along with `a’ and `i'. If you don’t accept `0i’ as valid, then
granted, there’s no contest for `0c’. But then perhaps `0a’ shouldn't be
permitted in an empty buffer either. At this point, however, the only
beneficiary is LOGIC.

For what it’s worth, I don’t believe that `0c’ was valid in Ken
Thompson’s ed, but I don’t have access to an old UNIX(tm) system at
the moment to confirm that. If so, you could use that in your
argument. But striving to do something reasonable before throwing an
error is part of the Unix philosophy, as outlined, e.g., in “The UNIX
Programming Environment” by Kernighan and Pike.
-AM



Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

[Prev in Thread] Current Thread [Next in Thread]