[Top][All Lists]

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

Re: [found the culprit]

From: Davis Herring
Subject: Re: [found the culprit]
Date: Wed, 14 Nov 2018 13:33:03 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

`Z' should be its own inverse.

This is a reasonable principle, but there is a reason to deviate from it here. The uncompressed tar format is so rarely used (partly because of the lack of actual tape drives, and partly because of change in the relative cost of CPU cycles and storage space) that having a convenient key to get _to_ it is unimportant. The unpacked and compressed-tar states, however, are both deserving of such a key. Therefore, whatever behavior (unpack or compress) we choose to apply to a .tar will not be inverted by a second Z -- because the initial state is presumed to be undesirable.

For example, on some machines I use, "git archive" cannot produce compressed archives. Having Z compress its raw .tar output would be, to me, a useful way of working around that limitation. But other users might prefer that Z unpack a .tar -- and then repack the resulting (hopefully single) directory into a .tgz.

Could Z query for which behavior to use in this (rare) case? That would provide an intuitive reason why a second Z would not necessarily reverse the process. (The query could even say so explicitly if it helped.)

Is it hard to hit two keys to uncompress + unpack?

Yes, because the operations are frequently slow and you wouldn't want to have to input a second key after a delay (or blindly).


This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping.

reply via email to

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