Hoi.
[2020-01-10 08:17] U'll Be King of the Stars <ullbeking@andrewnesbit.org>
> On 10/01/2020 08:13, markus schnalke wrote:
> >
> > GNU ed [...] seems to be more a demonstration
> > object than actually a programmer's editor.
>
> Hi Markus, in what way is GNU ed a "demonstration object"?
Thanks for questioning this statement! It seems as if I might have
mixed different memories up. A quick look at GNU ed showed nothing
to support my statement. Sorry for pretending stuff without fact
checking.
My look was at version 1.4, which is the newest one I could look
into. I'm pretty sure I examined GNU ed 1.6 back then, because
that version is in the Pkgfile of my system, but unfortunately I
am unable to find it anywhere. The GNU release mirrors lack all
version 1.5 through 1.10 -- why that? They must have been
released, at least 1.6, because that is used on my system.
Unfortunately I also was unable to access the Changelog of a
newer version to check for changes, because these are lzip
compressed (tar.lz) ... whatever that is, I cannot uncompress it
on my system. Furthermore I neither could find an online
browsable web repo view for checking out version 1.6 or at least
viewing the files within the browser. There's only a cvs repo
access (no cvs on my machine) and it talks about the web page
repo not the ed source repo. Not sure what to think of that.
That's not how things should be. Actually, I'm a bit depressed
now ...
GNU ed appears to be written entirely by one person (as in, no changelog entries by anyone else since 1994), who perhaps not coincidentally is also the author of the lzip compression program. As you noted, ed source is distributed only as lzip-compressed tarballs, so you have to be able to compile and run lzip to compile and run ed. lzip is written in C++, so to have access to GNU ed you need a C++ compiler. Which is very strange, as GNU ed is a very simple C program, much as one would expect.
The configure program is extremely basic, which is great - why have more than you need? - but when it detected that my $(CC) was not gcc, it hard-coded $(CC) to cc and $(CFLAGS) to -O2, ignoring what I had passed to the script. A strange choice, but one that can easily be edited later in the Makefile. The basic C source compiled with no warnings whatsoever, always a good sign. At the linking stage I noticed that I needed a library for some functions it wanted. Okay, easy enough, just add a library to the Makefile's LDFLAGS. But the Makefile had this braindamage:
$(progname) : $(objs)
$(CC) $(LDFLAGS) $(CFLAGS) -o $@ $(objs)
so on any platform that needs libraries linked after objects, it will fail.
At that point, I gave up. This is clearly one person's pet project and has "but it works on my Linux box!" written all over it. That, coupled with the fact that the GNU folks are willing to endorse something that is solely distributed in what can only be described as an extremely obscure compression format, was just too much for me to handle.
-Henry