GNU bug report logs -
#50097
gzip: add "--keep" option to keep original files unchanged
Previous Next
Full log
Message #47 received at 50097 <at> debbugs.gnu.org (full text, mbox):
On Fri, Aug 20, 2021 at 5:16 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> On 8/20/21 7:52 AM, Krzysztof Żelechowski wrote:
>
> >> echo hello >a
> >> ln a b
> >> gzip -k b && gzip -cd b.gz >>b
> >>
> >> This would trash 'a' if gzip -k succeeded. (Same with 'ln -s'.)
> >
> > The appending redirection operator has nothing to do with gzip.
>
> That's true even without -k: if plain 'gzip b' succeeded in this case,
> any problem that the user ran into later would have nothing to do with
> gzip. Plain 'gzip b' ignores 'b' here, not because compressing 'b' would
> cause any problem with gzip itself, but because it could cause confusion
> *later*.
>
>
> > My normal usage of (hard) links is as follows:
> > Create a file page.txt. Link it to page.html.
> > Want to view? Open page.html.
> > Want to edit? Open page.txt.
> > Want to attach? gzip -k page.html … oops.
>
> Oh my. That is ... unusual. Let's see if others chime in about whether
> this usage would justify changing the behavior of gzip -k.
We have decades of history across gzip, bzip2 and xz for the current
semantics of -k.
Generally, we have an obligation to try hard to avoid changing
semantics of existing options.
I.e., we have to weigh "what could go wrong?" against "what would be improved?"
In this case, the weights are small on each side. That alone argues against
making a semantics-changing modification to such a tool.
To compress a single file and keep the original, one can always read
it via standard input.
To summarize, while tempting to make the change,
it feels like too small a gain to justify changing semantics in a tool
like gzip.
This bug report was last modified 3 years and 78 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.