GNU /bin/ed 1.6 released | Hacker News Reader

ed 1.6 released

lists.gnu.org

73 pointslelf35 comments

"If you are packaging ed for a distribution, please, try to use the lzipped source tarball, as this can improve the support for the lzip format in packaging systems. Thanks."

Great. Now we have .xz, .lzip (.lz) and .lzma. Not to mention .7z - all using basically the same compression engine, with just enough differences to make them incompatible with each other.

with just enough differences to make them incompatible with each other.

It stopped being funny when tar ran out of letters.

-Z = compress, -z = gzip, -j = bzip2, -J = XZ

Now for lzip they had to resort to --lzip...

q e and y appear to be available (according to my man page).

There should be some kind of rule that if you run out of option letters your program is doing too much.

For comparison ls has e j and y available.

I am pretty sure someone's implementation (Sun?) of tar used y for bzip2 at some point.

well, with gnu tar I prefer to use:

  -a, --auto-compress
      use archive suffix to determine the compression program

So tar cvfa archive.tar.xz files* would create a tar.xz file

Doesn't work when piping the file to `tar`, though (e.g. `curl http://.. | tar x`). I've thus gotten in the habit of specifying the format I expect.

-a only works when creating the tarball anyway.

`file`-like auto-decompress could work, though: these formats have magic numbers, and tar already has the data in its zip_magic struct:

http://svn.netlabs.org/repos/ports/tar/trunk/src/buffer.c

together with code to infer compression type. I guess the only reason why tar doesn't support this already is caution.

-a does work with decompression, what version are you using? I'm using GNU tar 1.26, and just successfully used "tar xaf firefox-9.0.1.source.tar.bz2".

decompressing there's actually no need to use -a, you can do tar xf firefox-9.0.1.source.tar.bz2 (tar 1.25 here).

If you explicitly provide a file by path, then tar doesn't use magic number autodetect, but uses file extension dispatch instead. You would need to pass the data as a stream to force magic number autodetect:

      <firefox-9.0.1.source.tar.bz2 tar xaf -

Does that still work? It doesn't for me.

I was using (GNU tar) 1.20 and Debian stable is now at 1.23, but I think that autodetect code went in around 1.18.

But honestly doing the compression in tar instead of through a pipe doesn't actually help very much

Indeed, isn't this contrary to the unix way? Use tar for archiving, and pipe it through whatever compression utility you want.

The maintainer of GNU ed is also the author of lzip.

Though lzip predates xz, this GNU ed release is the first .lz file I've ever seen in the wild. Everyone else that distributes .tar.gz files (compatibility) along with .tar.something_else files (higher compression) seems to use bzip2 or xz, not lzip.

ed: the new hipster editor. Perfect for writing that Haskell to JavaScript compiler for your Node.js app.

Hahaha.

I made a `ed` cheat sheet years ago:

http://www.catonmat.net/download/ed.text.editor.cheat.sheet....

Remember that vim's ex or command mode (mode when you type ":") accepts `ed` commands. Level up!

Meh. Those of us who run ed-nightly have already enjoyed those features since New Year's Eve. <3 Gentoo.

http://www.gnu.org/fun/jokes/ed.msg

heh - I can't say I realised ed was still under active development - but the joke man page made me chuckle.

This can also be found distributed with Emacs.

http://git.savannah.gnu.org/cgit/emacs.git/tree/etc/JOKES?h=...

... Along with a bunch of other jokes, most of them making fun of Emacs. It's been there since ancient times.

I'm old enough to remember when this was poignant, and true (and when "eight" was moved to "eighty")...

    Eight
    Megabytes
    And
    Constantly
    Swapping

But man how far we've come in so short a time!

I've had to resort to ed a few times to rescue a system with no /usr partition. 'vi' or 'vim' happened to be in /usr/bin, so I needed to do some quick editing. Ed is definitely worth learning!

It's always good for systems administrators to be able to do things with one (or both) hands tied behind their backs. Murphy always seems to conspire to create a situation where those skills are necessary....

From the ChangeLog:

"All command-line options are now documented in the man page."

This should clear up any difficulty users may have had using the program.

I actually found studying ed (while reading _The Unix Programming Environment_ by Kernighan and Pike) to be really helpful in understanding sed and vim in more depth.

What does "8-bit clean" mean? I've seen that phrase before in regards to Nvi as well.

Looks like it means it handles 8-bit character sets properly. http://en.wikipedia.org/wiki/8-bit_clean

If you assume you'll never need the 8th bit of any given character (which you wouldn't, if you only ever handle pure 7-bit ASCII) you can safely use it for storing a single bit of per-character metadata to avoid consuming excess memory.

actually its wxactly the opposite

"GNU ed is an 8-bit clean, more or less POSIX-compliant implementation of the standard Unix line editor."

If the main implementation of ed isn't even POSIX compliant these days, I'd say POSIX is officially pointless.

Not entirely - it gives people a way to say "Unix-clone" without getting sued.

GNU has a long history of ignoring POSIX where they disagree with it. There's a much better chance that the BSD implementation will be fully compliant.

I use red, not ed. You can't be too careful.

This title is misleading. 'ed' was written long before GNU existed. Should probably read "GNU revision 1.6 of the Unix' ed command has been released".

Sad to see points of fact downmodded, no doubt by GNU fanboys. Wonder if we should also start calling Emacs' Windows port "Microsoft EMACS"?

Reply on news.ycombinator.com