Re: feature request: gzip/bzip support for sort

[Jim Meyering]

Dan Hipschman <address@hidden> wrote:
> On Sun, Jan 21, 2007 at 07:14:03PM +0100, Jim Meyering wrote:
>> Not to look the gift horse in the mouth, but it'd be nice
>> if you wrote ChangeLog entries, too.  And even (gasp! :-)
>> a test case or two.  Of course, we'd expect such a test case
>> (probably named tests/misc/sort-compress, and based on
>> tests/sample-test) to have this line in it:
>>
>>   . $srcdir/../very-expensive
>>
>> If you don't have time for that, I'll take care of it, eventually.
>
> Here's some tests.  They're actually not very expensive.  Of course,
> you need to "chmod +x sort-compress".
>
>
> 2007-01-22  Dan Hipschman  <address@hidden>
>
>       Test sort compression.
>       * tests/misc/Makefile.am: Add the test.
>       * tests/misc/sort-compress: New file containing the tests.

Thanks for all the work!
I've checked in your changes, then changed NEWS a little:

** New features

  By default, sort now compresses any temporary file it writes.
  When sorting very large inputs, this usually results in sort using
  far less temporary disk space and in improved performance.

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.

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?