A cool little feature to vi also is the inclusion of sed-like commands...

:%s/someword/some-other-word/g

is a valid command to exchange the words throughout your current file in the same way you would with sed.

Also to note is that the use of '/' is not required explicitly. You'll often end up building fences when you have to terminate a lot of characters when you're working with paths in commands like:

s/\/usr\/opt\/dir\//\/var\/opt\/dir\//g

Instead you could pick a different terminating character and simplify it for easier reading:

s_/usr/opt/dir/_/var/opt/dir/_g

I almost exclusively use

  perl -pi -e COMMAND

instead of sed for stream processing. I also use grep --perl-regexp in most cases. I need to remember Emacs and perl regex semantics; I'd rather not have more variants to remember.

And just like sed -i, perl -i supports adding a backup extension. Also you can get awk-like perl by using -a, for example:

  perl -nale 'print $F[1]' # note fields start at 0 unless you change $[

You can also make grep, but it's a bit long

  perl -ne 'print if /foo/'

It is a fairly comprehensive reference and all, but saying 'sed Editor' is just as bad as saying 'ATM machine'.

This is different, as sed is the proper name of the program (and just happens to be an acronym as well.) awk, while also being a stream editor, is not "a SED".

Anyway, complaining about redundant use of acronyms is IMO pointless and needlessly prescriptive. Language is a fluid thing.

It's worse in that it's not just redundant but actually conveys the wrong impression of its purpose... a bit like saying "yacc Compiler" or "File fsck".

Sorry, it's isn't comprehensive but more of an introduction, e.g. no mention of the difference between pattern and hold space or the n/N commands.

no mention on how to implement tetris in sed either. ( which would be the end of the road in sed-fu )

I think you're getting confused with implementing sed in sed. ;-)

I think I'll have to surrender my lisp noob badge forever after such an omission.

sed deserves a lot of love, I still prefer it for a lot of command-line munging, greps everywhere, bit of awk thrown in. That despite the fact that (say) perl -pe might do a more comprehensive or efficient job as basically a drop-in replacement with benefits.

Does/should a UNIX course nowadays bother training up students on these microprogramming languages if they're almost certainly going to have perl or python available anyway? They only marginally fit into the UNIX philosophy, so is it just their old-school cred that keeps them around?