Chris's Wiki :: blog/unix/EdNoLongerGoodEditor Commentshttps://utcc.utoronto.ca/~cks/space/blog/unix/EdNoLongerGoodEditor?atomcommentsDWiki2018-10-20T01:01:29ZRecent comments in Chris's Wiki :: blog/unix/EdNoLongerGoodEditor.By Greg A. Woods on /blog/unix/EdNoLongerGoodEditortag:CSpace:blog/unix/EdNoLongerGoodEditor:c4991d0e88011e37e557696877888df6703ee061Greg A. Woods<div class="wikitext"><p>BTW, editing on printing terminals and over slow and high-latency links was only part of the problem.</p>
<p>Another major issue is that computers back then were slow, very slow by todays standards, and of course they were also very expensive and thus rare.</p>
<p>The implication here is that you wanted to have a lot of people using the same computer, and per-character interrupts were very expensive, especially if they went through to user-land.</p>
<p>Back in university I worked on a VAX 11/780 with 60-odd terminals connected. Even just character echo in the kernel could swamp the CPU if everyone leaned on a repeating space bar at the same time, and thrashing was inevitable if too many people were punching the return key too fast. Even a million instructions per second doesn't go very far with that many users! :-) Worse yet was a PDP-11/60 with only about 16 terminals which we shared with a business class using WATBOL. Some of them learned about the batch job query command and started typing it and running it every few seconds to see how their jobs were progressing through the queue. Luckily there was a window between the terminal room and the computer room and you could see the activity light on the 11/60's front panel and it was relatively easy to show them how expensive it was to run that command so often and how it was slowing all their jobs down (never mind how it made our C compiles grind to a halt).</p>
<p>Meanwhile the local Multics machine which I also used had lots of printing terminals and many more relatively dumb CRTs, over 300 in all, and they were all connected through single-duplex lines (local echo in the terminal) or front-end processors that did the echo for you. The main CPUs could (usually) get on with real computing and thus it had true mainframe performance even with 300 active users. I found out very quickly though how much CPU full-screen editors took when I ran though an entire term's CPU budget (which for that class was already much higher than "normal", $300 vs. $100 if I remember correctly, since we were learning lisp using the interpreter) in less than a week while using Multics Emacs. Luckily my prof was happy to grant me more funny CPU money as he saw I was writing lisp extensions for emacs and learning even more than most of the rest of the class.</p>
</div>2018-10-20T01:01:29ZBy vermaden on /blog/unix/EdNoLongerGoodEditortag:CSpace:blog/unix/EdNoLongerGoodEditor:7f710d8d865dbc47c97118ab189eab1f86a17235vermadenhttps://vermaden.wordpress.com<div class="wikitext"><p>... and by the way - on that tiny djbdns/tinydns floppy appliance with edit(1) editor ed(1) was also not available :)</p>
</div>2018-09-09T18:07:53ZBy vermaden on /blog/unix/EdNoLongerGoodEditortag:CSpace:blog/unix/EdNoLongerGoodEditor:0dc9689120067b0b0d405535b3cba69284ce761bvermadenhttps://vermaden.wordpress.com<div class="wikitext"><p>I remember only one ocasion where vi(1) was not available. It was some very tiny djbdns/tinydns floppy appliance which had only edit(1) editor because adding vi(1) there - which was possible - took too much space and with other modules it just would not fit in the floppy.</p>
<p>Every other ocasion, no matter which version of Linux or UNIX, even some oldshoold AIX or HP-UX machines, there always was vi(1) available.</p>
<p>I agree with the author of the post, that vi(1) is the standard editor in UNIX land.</p>
<p>Learning ed(1) will be useful in context of for text parsing with sed(1) for example.</p>
</div>2018-09-09T18:06:17ZBy Stephen on /blog/unix/EdNoLongerGoodEditortag:CSpace:blog/unix/EdNoLongerGoodEditor:911f6985d1fe44a2e28689092de58e76445cfcfbStephen<div class="wikitext"><p>I have been using *nix for some 25 years. I have never once considered using ed. I have probably used sed any time ed would have been remotely useful. Thinking back I can't remember a time when I've needed to edit a file and couldn't use vi. </p>
<p>dc I use all the time. It is an RPN calculator. What's not to love.</p>
</div>2018-08-23T04:31:20ZBy Aristotle Pagaltzis on /blog/unix/EdNoLongerGoodEditortag:CSpace:blog/unix/EdNoLongerGoodEditor:6b280cf829dac1b9b59623b432856bf2d16fdba2Aristotle Pagaltzishttp://plasmasturm.org/<div class="wikitext"><blockquote><p>and if you are, something has generally gone wrong</p>
</blockquote>
<p>That right there seems like the one reasonable argument in favour of taking at least a cursory look at <code>ed</code> even before you <em>actually</em> need it: learning under duress is generally bad in terms of both learning outcomes and surefooted handling of the crisis. It’s good to not be totally unprepared the first time you find yourself dependent on it.</p>
<p>But that certainly doesn’t argue for spending a lot of time mastering it as a daily use editor.</p>
</div>2018-08-22T20:40:30Z