Re: bug in ed-0.3/ed-0.4

[Andrew L. Moore]

Claudio wrote:
] If Antonio does not want to handle them, I think we should put ed in
] unmaintained state again :(

I can offer two options:

1) ed 0.2 has some serious bugs - e.g., buffer overflows, unconditional
paging, longjmp vulnerabilities.  I can make a small patch to correct
the worst of these.

2) Code that I submitted as candidate for ed 0.3.  That work was
pretty much completed by me back in November, 2006.  It is much
cleaner, more correct and more robust than ed-0.2.  One problem is
that it has i18n support, but no translations. I am also in the
process of rewriting the documentation, which doesn't come easy to
me.

] It would be ok, but wasn't the original problem that you had not
] enough time to maintain ed in the first place?

Yes.

] Btw I experienced the same thing since I started my new full time job,
] as much as I loved maintaining idutils, I had to step down.

There are a couple issues.  It would nice if I had some say in who
my successor is. That doesn't seem to be FSF policy, which I hope
will one day be corrected.  The other is that fixes were offered,
but permission was evidently not granted to release them under a
dual GNU/BSD-like license so that they could be folded back into
the BSD release, of which GNU ed 0.2 is a port.  I consider that
another weakness of FSF policy that I hope can be reexamined one
day.

Paul wrote:

] Those of us left using 'ed' are doing so because we have very specific
] uses and purposes.  Maintaining essentially perfect compatibility is
] Job Number One.  There are -no-, -zilch- features that would justify
] rewriting half the code, because in doing so, it is essentially
] impossible to avoid inadvertent changes in corner case behaviour.

Agreed, although GNU ed 0.2 actually got some corner cases wrong.

] Changes, if any, should be done by small patches, that clearly
] accomplish one useful thing, with essentially zero side affects.  No
] changes in coding style or program structure.  For one thing, any such
] wholesale changes break the private patches I have carried against 'ed'
] for the last 20 years.

Paul, speaking of your patches, I was thinking about a possible
compromise to multiple file support which does not introduce "new"
(to GNU ed) syntax.  What if the "next" of multiple files were
opened after a `q' command? This has no impact on old scripts that
invoke multiple file arguments, expecting only the first to be
processed.  This implementation is about 3 lines of code.

] If you really have a hankering to write a better line oriented text
] editor, feel free to take the 'ed' source, rename it, and have a blast,
] in whatever way is allowed by its source license.

That has been done with sam and acme/wily.

On the other hand, I feel that patches which don't make it into the main
distribution might be offered in a contrib directory.  Readline
support comes to mind.
-AM