bug-gzip
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gzip and gunzip should have -k (--keep) option like bzip2 and bunzip


From: Bob Proulx
Subject: Re: gzip and gunzip should have -k (--keep) option like bzip2 and bunzip2
Date: Sun, 3 Dec 2006 07:02:17 -0700
User-agent: Mutt/1.5.9i

Shriramana Sharma wrote:
> Paul Eggert wrote:
> > Could you please explain why it is very difficult?
> > Is there something that "gzip -k FILE" would
> > do that "gzip <FILE >FILE.gz" does not already do?
> 
> Nothing, but I didn't even know that such a "trick" was possible.

Hmm...  Basic command line shell operation is not a trick.  Input and
output file redirection is a fundamental operation of the command line
shell.  Most users learn that '>' redirects the output of a command to
the file very early in their use of it.

> I am not as knowledgeable about these <> operators as you, and I
> suspect a lot of people will be there who have only as much
> knowledge as me, which is only so much as to try the app's manpage
> or -h help, and anything beyond that is out of my(our) range.

I can't believe this is typical however.  And now that you have
learned it you will have a new world of capability available to you.

> It's for such people as me that bzip2 has the -k option, and it's
> for such people as me that I ask that gzip also has that option.

If that is the reason then I don't think it is doing you any favors.
You would have no way of using 'cat' or 'grep' to create files for
example, and there are many others.  It is better to learn to do this
in the right place so as to be able to use the functionality the same
with all of the commands instead of differently with some commands.

> I do not think it would be very difficult for this to be included.

Just because something can be done does not mean that it should be
done.  Duplicating code in multiple places can always be done but it
is almost always a bad idea to do so.  It creates a maintenance
problem to keep the code in sync with each other.  When new features
are added or bugs fixed in one place then they need to be duplicated
in all of the other places as well.  It is a problem.

To avoid duplication of code and to provide consistency across
commands this functionality should be some place that is shared among
all of the commands.  This way all of the commands will have the same
redirection mechanism and a consistent implementation.  By design the
common place for this that is shared across all of the commands is the
command line shell.  The functionality is provided there for all of
the commands to use.

Bob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]