[TUHS] Posix ed weirdness

[Douglas McIlroy via TUHS]

> My guess is because that's what the "consensus" of implementations, or
> at least those willing to pay for POSIX certification, was.

Yes, that's roughly how malloc(0) got messed up. But the malloc(0)
anomaly at least had a rationale: 0-length data structures were
impermissible in bare C.

I suspect there was more politics afoot in the committee. I doubt that
many implementers would hit on the bizarre idea that deleting n-1
newlines should be special-cased for n=1. Curiously, Posix didn't
foist the same special-case behavior onto ex.

Doug

On Mon, Dec 15, 2025 at 7:11 PM G. Branden Robinson
<g.branden.robinson at gmail.com> wrote:
>
> Hi Doug,
>
> At 2025-12-15T16:55:54-0500, Douglas McIlroy via TUHS wrote:
> > The ed j command joins a sequence of lines into one line and sets dot
> > to the result. Thus
> >      2,4j
> > combines three lines and sets dot to 2. Naturally one expects
> >      2,2j
> > to make no visible change to the file, but to set dot to 2.
> >
> > Indeed, that's what v7 did. But Posix decrees that j "does nothing" in
> > this case and leaves dot at the value it had before the command.
> >
> > Does anyone know why the Posix committee chose to break both the
> > original behavior and  Kernighan's law: " 'Do nothing' gracefully"?
>
> My guess is because that's what the "consensus" of implementations, or
> at least those willing to pay for POSIX certification, was.
>
> $ uname -a
> SunOS gcc-solaris10 5.10 Generic_Virtual sun4u sparc SUNW,SPARC-Enterprise
> $ cat ward
> one
> two
> three
> four
> $ ed ward
> 19
> p
> four
> p
> four
> 2,2j
> p
> four
>
> Regards,
> Branden