From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1IaBCl-0000DT-Id for garchives@archives.gentoo.org; Tue, 25 Sep 2007 14:16:04 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.1/8.14.0) with SMTP id l8PE6Sfe016004; Tue, 25 Sep 2007 14:06:28 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.14.1/8.14.0) with ESMTP id l8PE20kG011024 for ; Tue, 25 Sep 2007 14:02:01 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id B65246559C for ; Tue, 25 Sep 2007 14:02:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 required=5.5 tests=[AWL=-0.536, BAYES_05=-1.11, DNS_FROM_DOB=0.732, RCVD_IN_DOB=1.103] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIJ8GlhiVe7i for ; Tue, 25 Sep 2007 14:01:54 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id E6F00655B0 for ; Tue, 25 Sep 2007 14:01:47 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IaAh1-0000t6-Ad for gentoo-user@gentoo.org; Tue, 25 Sep 2007 13:43:15 +0000 Received: from zy-rieter.cyberlink.ch ([212.55.215.153]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Sep 2007 13:43:15 +0000 Received: from listen by zy-rieter.cyberlink.ch with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Sep 2007 13:43:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Alexander Skwar Subject: [gentoo-user] Re: star Date: Tue, 25 Sep 2007 15:34:41 +0200 Organization: n/a Message-ID: <2734612.RV0q0BIfvm@kn.gn.rtr.message-center.info> References: <46F53CC6.30503@addcom.de> <200709221923.59083.volker.armin.hemmann@tu-clausthal.de> <46F55B7F.5010200@addcom.de> <200709222200.33355.volker.armin.hemmann@tu-clausthal.de> <1344772.8mdDTN8kXs@kn.gn.rtr.message-center.info> <2831404.7zBJE4lrJ8@kn.gn.rtr.message-center.info> <46F90C23.20204@gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: zy-rieter.cyberlink.ch User-Agent: KNode/0.10.5 Sender: news X-Archives-Salt: f982f4c7-66b8-41b6-bfda-a47ebaf48ecb X-Archives-Hash: 42d5320ebcbcb0b75af8e910b27eb9cb b.n. wrote: > Alexander Skwar ha scritto: >> Stroller wrote: >> >>> On 24 Sep 2007, at 09:30, Alexander Skwar wrote: >>>> ... >>>>> and if p7zip supports pipes, you don't need its support in tar. >>>>> Just pipe >>>>> from/to it. >>>> It does and that's the way it's supposed to be used on unix, according >>>> to its manpage. >>> GNU tar features the -j, -z and -Z options. >> >> Yes, bad, isn't it? These options are not part of the Posix standard. >> It would be good, if these superflous options wouldn't be present at >> all. I say "superflous", as pipes work just fine. > > It's not that an option becomes "bad" just because it's not carved into > the POSIX standard. To a degree, it is. > What's important, I guess, is that tar is > POSIX-compliant, so that if you want, you can build POSIX-compliant > scripts etc. , Depends. On the hand, you're right. But if non-compliant options exist, people tend to use them. That's bad in so far, as they get used to non-standard behaviour. That's especially bad, as standard compliants solution exist. > but I can't see how non-POSIX but handy extensions could > be bad. Let me give you a different example, although it has nothing to do with POSIX. Internet Explorer translates a \ in a URL to /. That's a non standard compliant behaviour. Now, as many people (still *G*) use IE, many people rely on that mis-behaviour of IE and make it hard for non-misbehaving browsers (ie. Mozilla) to display the content. What does this have to do with GNU tar and it adding superflous options? Quite a lot. -j et.al. are non-standard options. If a (badly written) script relies on the presence of -j, this script won't work with a POSIX compliant tar (like star or any Unix tar (eg. Sun, HP, ...)). Is that bad? Yes, it is. It is bad, as there's an easily accessible solution to this problem available: Use pipes! In this case, the solution would be: tar cf - dir | bzip2 > dir.tar.bz2 tar cf - dir | 7z a -si dir.tar.7z Or for decompression: bzcat dir.tar.bz2 | tar xf - 7z x -so dir.tar.7z | tar xf - > Maybe it's me not seeing the problem. Yep. > Maybe the POSIX standard > could just be extended as well. :) Equally fine. >>> and it would be nice to see p7zip supported >>> in the same way. >> >> No. > > "No" means nothing. Tell us why. Pipes exist. The current "integration" of 7-zip is fine. There's no need to integrate other compression into tar. Actually, there's no need at all to integrate ANY compression alg. into tar. Furthermore, especially with 7zip, an integration into tar would make the use of 7zip somewhat limited, as all of the additional command line options of 7z would not be accessible anymore. Alexander Skwar -- gentoo-user@gentoo.org mailing list