Re: feature request: gzip/bzip support for sort

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Jim Meyering on 1/24/2007 12:08 AM:
> Additionally, I'm probably going to change the documentation so that
> people will be less likely to depend on being able to run a separate
> program.  To be precise, I'd like to document that the only valid values
> of GNUSORT_COMPRESSOR are the empty string, "gzip" and "bzip2"[*].
> Then we will have the liberty to remove the exec calls and use library
> code instead, thus making the code a little more efficient -- but mainly,
> more robust.

Fair enough for now, as long as we leave ourselves an opening for future
expansion.  For example, the 7zip algorithm tends to produce smaller
compressed files than even bzip2 on typical input, and is patent
unencumbered, but my impression of 7zip is that it still does not behaves
as a filter compressor like gzip or bzip2, so it is not ready for
prime-time support yet.

> 
> If someone makes a good case for allowing an arbitrary compressor, we can
> allow that later.  But if we were to add (and document) this feature now,
> we might well be stuck with it for a long time.
> 
> [*] If gzip and bzip2 are good enough for tar, why should sort make any
> compromise (exec'ing some other program) in order to be more flexible?

New enough tar (1.16.1, for example), supports:
      --use-compress-program=PROG
                             filter through PROG (must accept -d)
along with the builtin recognition of gzip and bzip2.  However, rather
than linking in libraries, it always exec's, even for the known two formats.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFt1tn84KuGfSFAYARAqeoAJ9Zwstntak+XtKCRMgHwBaRWt7evgCgoypy
I8ymsCcFDib8l8wdzwpRROw=
=jnfm
-----END PGP SIGNATURE-----