Has anybody used the "Edit" shell command in recent years, and/or knows what it does?

[olsen]

The "Edit" shell command is one of the odder of the odd AmigaDOS shell commands. It's supposed to be a line editor which reads a file and then modifies it according to control commands which one can either enter manually, or have them read from a file. It's basically the AmigaDOS version of the Unix "sed" (stream editor) command.

As a matter of fact, the "Edit" command introduced with Workbench 2.0 never actually worked correctly. It either corrupted the files it read or crashed. Also, the documented features (e.g. in the AmigaDOS manual, 3rd edition) were not all implemented either. Which means that the command was basically useless, and has been for the past 20 or so years.

I'm curious if anybody here has ever used the "Edit" command, or even knows about its existance.

[olsen]

Probably I tried it in early 90's but as ed did so much more it was used until I found other, better editors. Can't remember if any problems popped up.

Interesting. "Edit" is sort of a precursor to the full-screen editors such as "Ed". While it does have an interactive mode of sorts, "Edit" isn't as useful as "Ed" for interactive operations. The point of having "Edit" is to give it instructions on how to modify the file being edited. As such it was supposed to be useful in script files, which "Ed" is not.

[olsen]

Most likely I was just lucky.

That's probably the best explanation ;-)

The reason why I asked my question back in 2011 was because after long deliberation I had decided to take the plunge and try to port the "Edit" shell command properly to AmigaOS4, making it reentrant.

During the course of this exercise I discovered that the AmigaOS 2.0 version was something of an odd port of the original BCPL version. Its companion, the "Ed" editor, fared much better in terms of how it was ported. Both "Edit" and "Ed" share some architectural decisions with regard to how the text is stored and modified in memory. The text is basically one big lump of memory which is chopped up into lines, with pointers referring to where the individual lines begin.

The problem with "Edit" was that how the text data was stored was inconsistent. In parts "Edit" wanted to treat the text as 'C' style NUL-terminated strings, in others it wanted it to be BCPL strings. It probably didn't help that the documentation for the command was somewhat inconsistent, too.

Anyway, when I was finished reworking the code I was uncertain if just maybe I had accidentally made something work correctly, and which might cause problems with users who had adapted to the quirks of the program over the years. "Edit" was supposed to be a command used exclusively in shell scripts, which would have aggravated the problem of "things now working differently than before", because shell scripts are notoriously difficult to debug.

So far it seems that my worries may have been unfounded. From my impressions whoever used "Edit" would limit the use of the command to those operations which didn't easily corrupt data or cause it to crash. Those commands still work as they did in the reworked version.

What works better now than before (read: doesn't crash, doesn't corrupt data), however, makes you realize how limited the "Edit" command is in what it does. The humble Unix "sed" is more powerful than "Edit" could be in its current form.

[olsen]

@olsen

Thank you for the insight on the current buggy status of the AmigaOS 3.x implementation of Edit.
I will definately stay away from the read function.

Is it possible by any chance, that you build a fix for 3.1 and/or 3.9 users that just addresess the most dangerous bugs it has? You could probably release it as a spatch file without issues.

It could happen. Much of the rework that went into making AmigaOS4 never was available to 68k AmigaOS users. There's a whole lot of interesting and useful stuff which, with little changes, could be released as part of an updated Workbench 3.10 or something like it.

The BCPL heritage in AmigaOS seems to be just a troublemaker everywhere it went

Well, it occasionally makes for good late night entertainment. The original "Edit" BCPL version, which I used as a reference to (sort) figure out if the problems were with the port or the original code, is one big lump of code. 47 KBytes of BCPL goodness with very few documentation comments to show you how it works or why it works.

One implementation detail which puzzled me was eventually cleared up after finding a description of the BCPL language and its operators. Apparently, BCPL has no modulus operator ('C' uses '%'), so the author of "Edit" needed to find a different solution which was more elaborate than it might have been in 'C', for example.