Zutils vs single compressor utilities

Hello,

As nobody responded to
http://lists.gnu.org/archive/html/bug-gzip/2009-08/msg00000.html, I am
sending this message again.

Vincent Lefevre (maintainer of the MPFR package) suggested that
utilities like zdiff, bzdiff, lzdiff, etc, should be provided
independently of compressors. So I have written a package named zutils
where I include such utilities with support for gzip, bzip2, lzip, xz
and uncompressed files. (Support for other compressors may be added later).

I am writing you because the most obvious names for such utilities are
the names of the utilities already distributed with gzip. I hope we can
cooperate to avoid name clashes in distributions. I think the best way
is gzip, bzip2 and lzip stop distributing their respective utilities and
distributions provide the zutils port/package to replace those utilities.

Alternatively, gzip utilities could be renamed to gzcat, gzdiff, etc.

The zutils package has been offered to GNU and is waiting approval, but
it seems coordination with the gzip maintainer is the main pending issue.

With zutils you can do:
zdiff file1.lz file2.gz
zdiff file1.bz2 file2
   or
zgrep "string" file1 file2.lz file3.gz file4.bz2

Zutils homepage is http://www.nongnu.org/zutils/zutils.html


Best regards,
Antonio.

[Jim Meyering]

Antonio Diaz Diaz wrote:
> As nobody responded to
> http://lists.gnu.org/archive/html/bug-gzip/2009-08/msg00000.html, I am
> sending this message again.
...
> I am writing you because the most obvious names for such utilities are
> the names of the utilities already distributed with gzip. I hope we
> can cooperate to avoid name clashes in distributions. I think the best
> way is gzip, bzip2 and lzip stop distributing their respective
> utilities and distributions provide the zutils port/package to replace
> those utilities.

Thanks for working on that.
However, I have a profound aversion to using a shell script
for any task that I require to be executed in a robust manner.

As such, my medium-term goal is to prototype a perl-based tool
using IO:Compress that can do the job more efficiently and more
robustly than bourne shell-based code can.

Jim Meyering wrote:
> However, I have a profound aversion to using a shell script
> for any task that I require to be executed in a robust manner.
>
> As such, my medium-term goal is to prototype a perl-based tool
> using IO:Compress that can do the job more efficiently and more
> robustly than bourne shell-based code can.

Are you sure a runtime dependency of the gzip package on perl is worth
the trouble?

In any case the coordination issue remains open.

If your future perl-based tools are for gzip files only, like the
current ones, then I think it is better to rename them to gzdiff, etc.

If your future perl-based tools are multi-format, then I think it is
better to package them independently of compressors. Meanwhile, I think
it is better to rename the current gzip-only scripts to gzdiff, etc.

What do you think?


Regards,
Antonio.

[Jim Meyering]

Antonio Diaz Diaz wrote:

> Jim Meyering wrote:
>> However, I have a profound aversion to using a shell script
>> for any task that I require to be executed in a robust manner.
>>
>> As such, my medium-term goal is to prototype a perl-based tool
>> using IO:Compress that can do the job more efficiently and more
>> robustly than bourne shell-based code can.
>
> Are you sure a runtime dependency of the gzip package on perl is worth
> the trouble?
>
> In any case the coordination issue remains open.
>
> If your future perl-based tools are for gzip files only, like the
> current ones, then I think it is better to rename them to gzdiff, etc.

IO::Compress is multi-format.

> If your future perl-based tools are multi-format, then I think it is
> better to package them independently of compressors. Meanwhile, I
> think it is better to rename the current gzip-only scripts to gzdiff,
> etc.
>
> What do you think?

Let's see how things stand in a month or two.