Hacker News Reader

Comment by dalke | Hacker News Reader

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 spent always looking up the "-i" (edit in place) flag, so I just use ed.

Also knowing a little 'ed' will make working with 'vi' easier, assuming 'vi' is not your usual editor.

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'.

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.

The only vi editor I used for more than a version commit was 'elvis' on Minux. Otherwise I'm an emacs user. (I know "q", "q!", "s", "dd", "i", "/", and "a". That's all I need for commits.)

The reason I found it humorous is my difficulty in coming up with strong reasons for someone to start with ed and then transition to vi, while it's easy to come up with reasons to start with vi and then learn ed.

And your best case examples don't come up often in my experience. I usually manually edit more than one line at a time. So it doesn't seem like a very pressing reason.

Out of curiosity, I looked for what sys admin jobs call for. "Significant experience in the use of at least one Unix-based editor (e.g., ed, vi, Emacs, pico)", "Can edit files using more than one editor", "Use vi editor extensively", "Regardless if you use joe, pico, emacs or MS Word for your daily editing, those will not be available in a rescue system and vi is different." Most fall into the vi camp, many only want a (common) editor, and only a handful say "ed - it's the unix editor!", and then only jokingly.

Oh! I almost forgot to mention. I used to use BSD Mail, and at the start I used the default editor, which was 'ed'.

Ah. I guess I didn't express myself very clearly. I'm not advocating starting with 'ed' and transitioning to 'vi'. I'm an emacs user myself. But as you know, emacs is not always installed by default (especially on remote server installations). 'vi' is always there, but I already know and prefer emacs. 'ed' is also always there, and catches some corner cases 'vi' doesn't. As a bonus to knowing 'ed' (in addition to a fullblown editor), should the occasion arise when it's convenient to have a visual editor and emacs is not installed, your knowledge of 'ed' will allow you to do useful things with 'vi', even if you never normally use it.

As to what sysadmin jobs call for, having knowledge of 'ed' is not something I would put in the requirements, but it is something I would ask during an interview as it would hint at knowledge of the myriad of obscure tools that unix has, and/or having tackled delicate problems that would have required a fallback to 'ed' in the past.

As such we're mostly in agreement I think. I agree there are no compelling reasons for learning 'ed' as your primary text-editor. But there are compelling reasons against not having a working knowledge of 'ed', although it depends to a large extent on your field of endeavour.

"I know just enough vi to compile emacs" ;)

I think knowledge of ed helps learning vi, just as knowledge of all the Unix programs that come before help learning Perl because it has so many influences. It always bemuses me that some people try to learn it as their first language. :-)

I had to use it more than once, typically when running on a hosed system, typically from within some miniroot/initrd/ramfs when the machine wouldn't boot and no full screen editor would run because of missing termcaps. However, cat is actually easier to use as a quick emergency editor (if you know how to use ^W,^U,^D and friends). Unless you're stuck using an ASR-33 :)

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 trying to write a one-line program to reformat text documents and it suddenly makes a bit more sense.

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 performance ends up being really unpredictable, while Perl's regex engine is fairly good and similar across platforms. (Also, I'm trying to avoid having to maintain both POSIX-style and PCRE-style regex syntax in different scripts, but that may be a matter of preference.)

Good old Perl Pie!

That's the usual attitude, I think. "I'm glad I know how to use it now, but I hope I never have to."

Reply on news.ycombinator.com