Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: olsen on May 03, 2011, 09:24:37 AM
-
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.
-
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.
-
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.
-
Old thread revival :)
Yes, I have used Edit quite a bit, and never really had any issue with it crashing. It is truly a fun adventure to use it, sort of like a text adventure of the board game "Roborally", hehe.
-
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.
I always used CED for such work....
-
I always used CED for such work....
Well, the purpose of EDIT is rather to automate edits for scripting, and for that CED is not well suited. EDIT could, in principle, do this. However, it's arcane syntax is not really helpful. I personally use my edition of SED for this purpose - the syntax is probably not less arcane, though based on the AmigaDos wildcards, but at least the beast works.
-
One thing I recall using edit for fairly recently, was editing output from C:date command, to "translate" them to strings that c:date would understand as input. Output from c:date is always localized, but it _only_ accepts English input, so names of months have to be replaced. I had a timestamp file that was written to regularly, and on boot, the content would be parsed through edit and fed to c:date. Later I went to not using content, but only the timestamp of the file, using c:setdate to "touch" the file with a new timestamp every now and then. Ideally I wish C:setdate could "touch" the filesystem creation date too, which AmigaOS uses as start time for systems without RTC, and/or that C:date could set system time based on the timestamp of a file/filesystem. A small gem on aminet btw, is http://aminet.net/package/util/time/TimeKeeper .
-
I currently use edit in my installation scripts to make modifications to the startup-sequence without user intervention.
This saves me, and the not so skillfull users a lot of grief.
It is indeed a very powerfull tool that often gets overlooked.
-
The only command I ever used was "q" to quit when I unintended started the editor ;-)
-
http://wiki.amigaos.net/wiki/AmigaOS_Manual:_AmigaDOS_Using_the_Editors#EDIT
-
Yeah, Edit has always been a bit of a mystery to me too. Use Ed all_the_time though to modify my startup-sequences, text files, etc. Just be sure to delete the Ed-Startup file in S for a little more GUI flexibility.
-
I only used the insert feature of the edit command with some search and line position placement. Nothing too complex, but never encountered the bugs that olsen claims it has.
Most likely I was just lucky.
-
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.
-
In my view, sed and edit are different beasts - sed is a "stream editor", working on data streams, while edit is more like a normal editor, except you are pretty much editing blindly. The UNIX equivalent of Amiga "edit" would be "ed".
-
In my view, sed and edit are different beasts - sed is a "stream editor", working on data streams, while edit is more like a normal editor, except you are pretty much editing blindly. The UNIX equivalent of Amiga "edit" would be "ed".
"edit" can certainly be run in non-interactive mode by proper redirection, and as far as I understand, that's the intended purpose. Otherwise, the "user interface" is pretty much a joke.
Except that it is too limited to be really useful. It's one of the left-overs from original tripos. Get "SED" from the aminet, does its job and is more powerful.
-
The names always seemed a bit mixed up to me -- "ed" is more vi-like and "edit" is more ed-like. I never learned how to use "edit" but it seems pretty nice as far as line-wise interactive editors go, with things like "insert after". OK, my only reference is Unix ed, the STANDARD Unix editor...
-
@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.
The BCPL heritage in AmigaOS seems to be just a troublemaker everywhere it went :)
-
Well, the purpose of EDIT is rather to automate edits for scripting, and for that CED is not well suited. EDIT could, in principle, do this. However, it's arcane syntax is not really helpful. I personally use my edition of SED for this purpose - the syntax is probably not less arcane, though based on the AmigaDos wildcards, but at least the beast works.
i am not in any way a programmer. i never use scripts, and automating scripts.. way over my head.
i preferd CED for editing startup-sequence or user startup, or anything related.
-
"ed" is more vi-like
A really really really user-friendly version of vi, maybe.
I can see the similarities but vi is horrid with unmemorisable strings of commands to insert lines or delete characters. Ed does have such commands, but basic editing is possible without them, and any commands you might need are helpfully available from the menu.
I'll happily use Ed, but will avoid vi like the plague.
-
And I use vim for just about everything, every day :)
-
@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.
-
A really really really user-friendly version of vi, maybe.
I can see the similarities but vi is horrid with unmemorisable strings of commands to insert lines or delete characters. Ed does have such commands, but basic editing is possible without them, and any commands you might need are helpfully available from the menu.
I'll happily use Ed, but will avoid vi like the plague.
Each to their own, I guess. For me, since my job involves writing and changing many lines of text, the investment in learning the basics of vi and vim is a small one. To get to the point where you've covered all the ed editing features, you need to learn maybe 10-15 commands only superficially, and then you can get into the details that make editing in vi quicker in the long run, like marks, motions, regular expressions and auto indentation.