From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: [found the culprit] Date: Wed, 14 Nov 2018 11:58:28 -0800 (PST) Message-ID: <6d51f735-30f2-4310-b9b3-7300241c4a21@default> References: <875zx1xgiq.fsf@mat.ucm.es> <83lg5w9956.fsf@gnu.org> <87d0r76ewm.fsf_-_@mat.ucm.es> <87tvkjq2mh.fsf_-_@mat.ucm.es> <834lcj8y1f.fsf@gnu.org> <874lcjoauq.fsf@mat.ucm.es> <340d2bf9-46b9-4bb3-aea6-0f4dd507b6cd@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1542225470 11974 195.159.176.226 (14 Nov 2018 19:57:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 14 Nov 2018 19:57:50 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 14 20:57:46 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gN1II-00031S-1H for ged-emacs-devel@m.gmane.org; Wed, 14 Nov 2018 20:57:46 +0100 Original-Received: from localhost ([::1]:33942 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gN1KO-00047f-IJ for ged-emacs-devel@m.gmane.org; Wed, 14 Nov 2018 14:59:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gN1JK-00045r-60 for emacs-devel@gnu.org; Wed, 14 Nov 2018 14:58:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gN1JH-0003QR-Gw for emacs-devel@gnu.org; Wed, 14 Nov 2018 14:58:50 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:38966) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gN1JF-0003K2-Mc for emacs-devel@gnu.org; Wed, 14 Nov 2018 14:58:47 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id wAEJwZ2P086234; Wed, 14 Nov 2018 19:58:37 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=78Q4EfHSG723puYbLrFvaeOCF2Ia/K32nDBjEzJnh7A=; b=mtML8zXLPUjxUj9UU9bUzR78CvZ1TUPRV7DL3hntKp5v0N6jNooEzQTtFLxmESv7wpFb lgQicltFmbJRx2sjT1ROe3D9oXKaEkaOJoFv8B0vvG41Hs6k0/FvigKsOBa+qvxMomqb QpB7Kzf+3nMEmMOkKFJfXjs4ABZ21F/SLnrEyYSYkm4Y1EAj60QeE35T0A+3hYgIcr3G q2Rr+0H3gtIKKU5A4m9XC+HRf53hQuUmKd9ntCT5tgVwnrvdSINdI9avUBtzuHZZ5ODk eSXknb8akfnCqhLeq0ruY5kcpAGUKzga04sQ5XV8UsZHURPEIrcyVzVjXE1kRYDdHiMJ UA== Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2120.oracle.com with ESMTP id 2nr7cs5pqd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Nov 2018 19:58:37 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id wAEJwVlk016769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Nov 2018 19:58:32 GMT Original-Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id wAEJwT4F029666; Wed, 14 Nov 2018 19:58:31 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9077 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=804 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811140177 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 141.146.126.78 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:231147 Archived-At: > The question is not "what do we do when we receive an uncompressed tar > file", but rather "what do we do when we have a compressed tar file" > and "what do we do when the user requests to compress a directory". `Z' should do what it's long done. But if you want to give it a special behavior for directories, I have no objection. I already said that the particular command can have behavior that treats exceptions exceptionally. The exception is for directories - we should not change the whole `Z' command for all tar and tar.gz just because we want to do something special in the case of directories. As for the behavior that you want - the new `Z' behavior: just define it as a new, different command. Give it another key, if you think that's needed. I don't see why the general behavior of `Z' should be changed for tar/tar.gz/.tgz, just because of the desire to do something better for directories. > in my experience ".tar.gz" is itself considered as an > archive format rather > than "a compressed file which contains an archive" Fair enough. But that's not the only way it's considered, I think. It is still possible, at least outside Dired, to uncompress without extracting, right? > in the sense that in the vast majority of cases people > take a directory and pack it up into a .tar.gz "tarball" > or take a ".tar.gz" and unpack it into a directory tree: > the cases where the .tar intermediate step is used > explicitly are much less frequent. Yes, though an exception, the directory case is common. ;-) It's an exception, in that its only one thing you can tar up and compress. But you're right that it is very common. Maybe we should have a separate command for it? > > The question is whether `Z' should support tar files. >=20 > No. It does and has done so for a long time and there's > no suggestion to make it stop supporting it. >=20 > And indeed Dired's `Z` has been compressing directories to tar.gz and > uncompressing tar.gz to directories (rather than to tar files) for many > years now. So what's new is that it now does the same for non-directories? If so, why is that good/needed? Maybe I'm misunderstanding what this is all about. If so, I'm sorry for all the noise.