3 ms·

More about ed - http://en.wikipedia.org/wiki/Ed_(text_editor) http://en.wikipedia.org/wiki/Ed_(text_editor) It was one of the first end-user programs hosted on

by duck 16y ago

More about ed - http://en.wikipedia.org/wiki/Ed_(text_editor) http://en.wikipedia.org/wiki/Ed_(text_editor) It was one of the first end-user programs hosted on the system and has been standard in Unix-based systems ever since. ed was originally written by Ken Thompson and contains one of the first implementations of regular expressions. ... Famous for its terseness, ed gives almost no visual feedback. For example, the message that ed will produce in case of error, or when it wants to make sure the user wishes to quit without saving, is "?". It does not report the current filename or line number, or even display the results of a change to the text, unless requested.

cag_ii 16y ago
Even more about Ed: http://www.gnu.org/fun/jokes/ed.msg.html http://www.gnu.org/fun/jokes/ed.msg.html
rudin 16y ago
I think everyone should spend an evening trying to write in ed. Knowing that most of unix was written in this simple editor shows the power of tight constraints in design decisions and the creativity that can come from them. It also makes the whole cascade of editors ed/vi/vim/... more understandable.
- wazoox 16y ago
  However ed is actually easier to use on a true teletype, where everything you print is actually... printed.
- coliveira 16y ago
  I did this exercise, and to tell the truth, it works better than "normal" editors for some tasks. For example, fixing bugs from a C compilation, checking a particular line, finding some structure on file based on regular expressions. Nowadays, I use ed regularly whenever possible. I even wrote a blog post on my experiments: http://coliveira.net/software/using-ed-the-standard-unix-editor/ http://coliveira.net/software/using-ed-the-standard-unix-edi...
bluesmoon 16y ago
One of the reasons ed is so terse is because bandwidth was really expensive back when it was written. Not necessarily in terms of money (since everyone was at a university), but in terms of time. If your editor were to echo back everything you'd typed, you'd waste twice the bandwidth (once to send a keystroke in and once to get it echoed back). Though in reality it would be more like 4 times because each character sent through would require a TCP-ACK packet sent back. By saying nothing, ed became really fast. sed took things to the next level. If you already had a file on a remote system, and wanted to make changes to it, all you had to do was note down the 'ed' commands to make those changes, and then tell sed to run them. You didn't have to open ed to operate on the file, you just had to send your commands over the network and sed would operate on the file remotely. A more efficient rsync, if you will.
- enf 16y ago
  It wasn't network bandwidth actually, it was printing speed. When your terminal can only print ten characters per second, terseness is even more of a virtue than it is on a slow network.
- mturmon 16y ago
  ed preceded TCP (first ed manual I could find is dated 1971; the first TCP research paper was by Cerf and Kahn in 1974). When ed was used, it would be common to interact with the computer on a teletype, not even on a crt monitor. So a response meant printing characters on paper. sed was and is more about programmatic editing (i.e., editing a stream as it was generated, using a script for commands), or editing of large files that would overwhelm system memory, not about some kind of remote usage the way you're describing.

by duck 16y ago

cag_ii 16y ago

Even more about Ed: http://www.gnu.org/fun/jokes/ed.msg.html http://www.gnu.org/fun/jokes/ed.msg.html

rudin 16y ago

I think everyone should spend an evening trying to write in ed. Knowing that most of unix was written in this simple editor shows the power of tight constraints in design decisions and the creativity that can come from them. It also makes the whole cascade of editors ed/vi/vim/... more understandable.

wazoox 16y ago
However ed is actually easier to use on a true teletype, where everything you print is actually... printed.
coliveira 16y ago
I did this exercise, and to tell the truth, it works better than "normal" editors for some tasks. For example, fixing bugs from a C compilation, checking a particular line, finding some structure on file based on regular expressions. Nowadays, I use ed regularly whenever possible. I even wrote a blog post on my experiments: http://coliveira.net/software/using-ed-the-standard-unix-editor/ http://coliveira.net/software/using-ed-the-standard-unix-edi...

bluesmoon 16y ago

One of the reasons ed is so terse is because bandwidth was really expensive back when it was written. Not necessarily in terms of money (since everyone was at a university), but in terms of time. If your editor were to echo back everything you'd typed, you'd waste twice the bandwidth (once to send a keystroke in and once to get it echoed back). Though in reality it would be more like 4 times because each character sent through would require a TCP-ACK packet sent back. By saying nothing, ed became really fast. sed took things to the next level. If you already had a file on a remote system, and wanted to make changes to it, all you had to do was note down the 'ed' commands to make those changes, and then tell sed to run them. You didn't have to open ed to operate on the file, you just had to send your commands over the network and sed would operate on the file remotely. A more efficient rsync, if you will.

enf 16y ago
It wasn't network bandwidth actually, it was printing speed. When your terminal can only print ten characters per second, terseness is even more of a virtue than it is on a slow network.
mturmon 16y ago
ed preceded TCP (first ed manual I could find is dated 1971; the first TCP research paper was by Cerf and Kahn in 1974). When ed was used, it would be common to interact with the computer on a teletype, not even on a crt monitor. So a response meant printing characters on paper. sed was and is more about programmatic editing (i.e., editing a stream as it was generated, using a script for commands), or editing of large files that would overwhelm system memory, not about some kind of remote usage the way you're describing.