Live data from Hacker News

Actually using Ed

blog.sanctum.geek.nz

51–60 of 92 posts

Re: Actually using Ed

#51
post #47
post #43

Earlier quoted context omitted.

> Arch Linux setup does not actually have ed. They did specify Unix.

I don't know if unix is the most ahem "specific" specification ever given. What specification of unix do you think the author was referring to? In any case, they have corrected themselves in the blogpost.

well, if he was referring to 'unix' as specified in the Single Unix Specification (which incorporates IEEE Std 1003.1)

then all unix systems have 'ed'

http://pubs.opengroup.org/onlinepubs/009695399/utilities/ed....

If arch linux doesn't include it, it's not a 'unix'; it's not even a good "not unix". So the author wouldn't have needed to correct his article but Arch would need to include 'ed' :)

Re: Actually using Ed

#52
post #40

I'm glad ed is there. I'm glad articles like this are there. But there is no way I'll have retained that article in the moment my terminal has borked and I actually need ed. I wish that something like this available in the man pages, or something like them, or at least referred to in them. Because maybe I'm not clever enough but I don't find the man page articles to be very good introductions. As reminders of syntax…

Linux man pages are notoriously verbose, and often obtuse and incomplete, this is in great part due to the extra complexity of GNU tools and their preference for the infamous info documentation system. OpenBSD has probably the best Unix manual pages: http://www.openbsd.org/cgi-bin/man.cgi?query=ed And Plan 9 has a manual that is a pleasure to read, this is helped in part because the commands themselves have been clea…

I dream of a system with features such as iPython live doc, or Bret Victor's tangle. It seems an approachable goal nowadays.

Re: Actually using Ed

#53
post #9

Earlier quoted context omitted.

You may occasionally want to use its little brother, `sed`, which has substantially similar syntax. It is often the case in Unix programming that you have a pipe full of text data and you would like to transform every line of it; `sed` allows you to write these transforms into one line of instructions on the console line. So it may sound crazy that you have all of these terse commands, but just imagine that you're tr…

I used to use sed, but more recently I've been using 'perl -pe' instead, which is a drop-in replacement for the basic 's//' use I typically make of sed. The main reason is that I've had some performance problems with sed, depending on which of the several sed variants is installed. Many of them seem to have small fixed buffers that really limit throughput when processing large (multi-gigabyte) files, and the performa…

Good old Perl Pie!

Re: Actually using Ed

#54

Earlier quoted context omitted.

On many systems you should be able to unbork the terminal with 'reset' or 'tput reset'. Then you do not need ed ;)

That's only going to fix a few causes of borked-ness. If the remote system doesn't have a termcap for your terminal, reset doesn't do much. In that case, setting TERM=vt100 will probably help matters, unless you're on a really obscure terminal of some sort.

I think my underlying point is that it's fine to learn ed, but if the problem is that you are borking your terminal then there are actually ways around that. These days it should almost never happen that you are sitting around tolerating a broken terminal. This is not an efficient use of time. The actual modern use cases for ed are not very common. If you want to learn it just for kicks or because you think it's cool then that is another thing.

Re: Actually using Ed

#55
post #37
post #20

Earlier quoted context omitted.

Why? We have better alternatives, and clearly things can work without it.

What better alternatives are there? Even if you prefer vi for interactive edits, I still prefer ed for small edits. Then there are times when your terminal is borken (or as somebody mentioned, perhaps even your keyboard is broken), this still happens more often than you think. Recently I had to use some ajax-term thing which was just awful and completely unable to run vi properly for who knows what reason, anything t…

There are many editors which will do the job, it is a matter of taste. If you break your terminal by some obscure action, then fix it rather than choosing your entire toolchain around the premise that you will be spending significant time in a broken terminal.

I appreciate historical respect for the tool but this falls short of showing it to be indispensable to everybody.

Re: Actually using Ed

#56
post #4

No thanks, I'm sticking with TECO.

Here's a TECO that will actually work on modern systems (that is, it's not written in PDP-10 assembly language):

http://videoteco.sourceforge.net/

And the manual:

http://www.copters.com/teco.html

More information:

http://c2.com/cgi/wiki?TecoEditor

Re: Actually using Ed

#57
I was a MUD coder in a past life (and sort of am still); learning ed is essential for that environment. I'm glad I learned to use it, and gladder still I don't have to use it every day.

It's great for quick fixes and one-offs, but having to engineer with it is rather unpalatable.

Re: Actually using Ed

#58
post #46
post #2

That was a good explanation. I hope never to have to use ed.

Even today 'ed' has practical uses apart from being the default emergency backup of the backup editor. One situation where I always use 'ed' is when I reinstall a machine (with the same ip) and ssh tells me the keys don't match together with the line number in the file known_hosts. It's easy as: #ed ~/.ssh/known_hosts 15d wq (assuming the mismatching line was 15). Only sed would be faster if it wasn't for the time sp…

Learn ed so that vi becomes easier - nice joke!

More relevant is that I already know a bunch of tools for doing deletion of line 5. For example: perl -i -ne 'print unless $.==15' . It's more complicated, but it's a smaller number of tools for me to remember.

Actually, I probably would have used mv to a temp file + awk 'NR!=15' + rm temp file. Even knowing perl and python I still use awk pretty often, and it comes to mind much easier than thinking about ed or sed. Plus, I still have the temp file around in case I need to revert a mistake, like if I accidentally typed '51' instead of '15'.

Re: Actually using Ed

#59

Having been a user of *NIX for over 20 years and a professional Systems Administrator for over 10, I have never once had a reason to use ed. Even the smallest embedded environments usually have some variant of vi available. The only time that I've needed to use ed was edlin in the dark days of early MS-DOS, which is very similar. This is borderline masochistic.

You narrowly missed the days when it was useful. When I started regularly sysadmining in the late 80s/early 90s (after being a mere user for the a few years) I found I had to learn ed. /usr was always a separate filesystem so any time there was a problem booting you didn't have vi available. If you didn't have at least rudimentary ed skills fixing the simplest problems would be rough.

In linux at least the separate /usr never seemed to get that popular. If you can mount the root filesystem you've got basically the whole OS at your disposal.

I will say that learning ed (or, better yet, ex) well does make you a more efficient vi user. When all you have is command-mode you get very adept at using it. It's actually sort of fun, too. Just hit "Q" in vim some time and see how you do with only ex commands.

Re: Actually using Ed

#60
post #58
post #46

Earlier quoted context omitted.

Even today 'ed' has practical uses apart from being the default emergency backup of the backup editor. One situation where I always use 'ed' is when I reinstall a machine (with the same ip) and ssh tells me the keys don't match together with the line number in the file known_hosts. It's easy as: #ed ~/.ssh/known_hosts 15d wq (assuming the mismatching line was 15). Only sed would be faster if it wasn't for the time sp…

Learn ed so that vi becomes easier - nice joke! More relevant is that I already know a bunch of tools for doing deletion of line 5. For example: perl -i -ne 'print unless $.==15' . It's more complicated, but it's a smaller number of tools for me to remember. Actually, I probably would have used mv to a temp file + awk 'NR!=15' + rm temp file. Even knowing perl and python I still use awk pretty often, and it comes to…

not a joke at all. A regex you use in 'ed' command mode, you can use directly in vi after typing ':' I never made any heavy use of 'vi', but I can use it because I know a little 'ed'. Conversely, if one knows 'vi', it's easy to use 'ed' when one needs a tiny edit and doesn't want the whole screen to be filled. Even though it's just a moment, I find it distracting, especially in the ssh case I mentioned where I expect to login over ssh and suddenly I would need to change the whole screen just to make a trivial edit; 'ed' is a real timesaver there because it hardly disrupts the workflow.

I guess the benefits of 'ed' depend on your line of work though. For a systems administrator, I would make it a job-interview question.

Post reply on HN