Live data from Hacker News

Actually using Ed

blog.sanctum.geek.nz

71–80 of 92 posts

Re: Actually using Ed

#71
post #60
post #58

Earlier quoted context omitted.

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…

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

Re: Actually using Ed

#72

I think a lot of C programmers would find reading the source to the V6 ed interesting: http://www.tuhs.org/Archive/PDP-11/Trees/V6/usr/source/s1/ed.c 1333 lines of C, basically no library use at all (no printf, not even malloc -- the only thing dynamically allocated is the document, and it uses sbrk() to manage the memory itself), compiles down to about 6K on a PDP-11. And that includes a regex engine! It contains a…

I remember doing a=+1 in K&R days under IRIX and getting a warning that "=+" was deprecated. I had just started with Unix then, and had to get someone else to explain the source of that message.

How does the "goto errlab" work? It looks like it calls errfunc() then gets to the reset(), which doesn't return. Does setexit() determine the entry point for a reset?

This really is a bare bones system. An insert at the start shifts every character to the right by one, and memory growth is only 1024 bytes at a time. This leads to quadratic times. I wonder if that performance was noticeable on the PDP-11 when editing a large-for-the-time file.

Re: Actually using Ed

#73
post #72

I think a lot of C programmers would find reading the source to the V6 ed interesting: http://www.tuhs.org/Archive/PDP-11/Trees/V6/usr/source/s1/ed.c 1333 lines of C, basically no library use at all (no printf, not even malloc -- the only thing dynamically allocated is the document, and it uses sbrk() to manage the memory itself), compiles down to about 6K on a PDP-11. And that includes a regex engine! It contains a…

I remember doing a=+1 in K&R days under IRIX and getting a warning that "=+" was deprecated. I had just started with Unix then, and had to get someone else to explain the source of that message. How does the "goto errlab" work? It looks like it calls errfunc() then gets to the reset(), which doesn't return. Does setexit() determine the entry point for a reset? This really is a bare bones system. An insert at the star…

Yes, setexit() and reset() were the precursors to setjmp()/longjmp(): http://man.cat-v.org/unix-6th/3/reset

Re: Actually using Ed

#74
I think sed pretty much displaced ed. I still use ed but sed offers the same functionality and it's easier to script. One exception is the j command for joining lines.

For better or worse, in some of today's base Linux distributions, you might find ed missing. You will almost always find sed though.

Re: Actually using Ed

#75
post #48

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.

It's not whether 'vi' is available (it usually is), but whether it is behaving properly. Situations do occur where any fullscreen editor will fail and where 'ed' will work as expected. And at such moments, even though you don't know the full extent of the power of 'ed' you will be happy to know how to change a line and save the config file (and actually quit 'ed'; that's harder than it sounds) An editor in ne ed is a…

Can you give a specific example? I have a not insignificant amount of experience with thousands of servers under my belt and I have yet to ever need to type "ed" into a server. I did find edlin useful in DOS 4, but that was ancient times.

Re: Actually using Ed

#76
post #26

I guess I'll date myself by saying that when I started studying CS, I used ed and thought nothing of writing programming assignments with it. It seemed totally natural. I recall a typical sequence of writing a few lines and then printing out a block of lines to the screen to check. Then jumping somewhere else printing out a block of lines, editing some more etc. I recall hearing about vi and thinking it was overly co…

What year was this?

Re: Actually using Ed

#77

Earlier quoted context omitted.

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.

That last happened to me fairly recently, when a server was unable to mount /usr (where the termcap stuff lives) and I had to use ed to edit the RAID config files so that I could mount it. Fun times.

Ouch, more extreme than I was thinking. I've encountered systems that don't like screen or urxvt or what have you, but they still had vt100 and that's a useful subset of the termcap of most modern terminal emulators. If there's no /usr at all, that's certainly a stronger argument for ed!

Re: Actually using Ed

#78
post #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.

I'm curious, why is it essential? I'm a bit of a MUD enthusiast myself, and I've never had to use ed. On the other hand, my favorite MUD's long-form editor (like for newsposts and journal pages) has an ed-like design.

Re: Actually using Ed

#79

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…

My survival kit for linux man pages is "/" for search and then "n" until option is found.

Re: Actually using Ed

#80

I think a lot of C programmers would find reading the source to the V6 ed interesting: http://www.tuhs.org/Archive/PDP-11/Trees/V6/usr/source/s1/ed.c 1333 lines of C, basically no library use at all (no printf, not even malloc -- the only thing dynamically allocated is the document, and it uses sbrk() to manage the memory itself), compiles down to about 6K on a PDP-11. And that includes a regex engine! It contains a…

It probably also has vestiges of the assembler version in its structure and symbols. troff(1) certainly has; I had trouble groking one particular function's logic and asked Kernighan. He kindly replied and said that one had always troubled him too and was just a transliteration from Ossanna's assembler. Glad it wasn't just me. :-)
Post reply on HN