5 ms·

Remove z option in tar? Where did that come from?

Annatar 10y ago
From the fact that tar is a tape archiver, and according to the UNIX philosophy of "do one thing and do it well" it should empathically not dub as a (de)compressor. GNU implements tools inside of other tools. Emacs is a perfect example if that.
- qwertyuiop924 10y ago
  GNU didn't originate from a unix mindset. You should know this. That doesn't mean their software is bad. Also, Emacs is incredibly useful, and one of the best general-purpose text editors out there.
  - Annatar 10y ago
    GNU didn't originate from a unix mindset. You should know this. I do and oh-how-right you are. What I have major difficulty with is comprehending why people like it, and why they tolerate Stallman's nonsense when there are alternatives. The "rip it all out because it's not ours and re-invent everything just because" attitude is so fundamentale broken.
    - qwertyuiop924 10y ago
      As somebody who does tolerate Stallman's nonsense, I can tell you why: It's because some of his software is really good. Like Emacs. I'm willing to bet that you're a VI user, but for us Emacs users, there really is no substitute. And if you want a Scheme package, Guile is a really good one (although it's not as efficient as some of the compiled schemes): Andy is doing a great job with it. There are other examples, like tar (I know you would disagree, but dammit, GNU tar is so useful). When there isn't, or Stallman deliberately cripples his software, there are usually alternatives (clang, etc.) which we use, unless "we" are FSF people. Which most of us aren't. Yes, his attitude is somewhat broken, although I understand why it exists. Also, he's not quite as NIH as you seem to think: There are several cases where he advocates use of software that isn't his own (heck, he advocates clang, or at least has no problem with it). Also, I have no objection to long options, or to utilities that are a little bit richer (just so long as they still interoperate, and you can still use the standard options, which is usually the case).
      - Annatar 10y ago
        I'm willing to bet that you're a VI user, And you'd win that bet. Not even a vim user (except on Amiga), but straight vi. Why? Because vi was always there when I needed a text editor, and by learning vi, I automatically learned ed, sed, and ex. All of a sudden, I could write multi line sed programs.
        qwertyuiop924 10y ago
        Hey, I get it. I've always have the sneaking suspicion that VI users are way more productive at actually editing. But I know for a fact that they don't have the extensions that make editing dynamic languages (especially lisp) in Emacs so efficient. And there's no use learning another editor just to write C: What do you think I am, and IDE user?
- crististm 10y ago
  In that case you mean option -x not -z. Either way, there are several philosophies and schools of thought. Many of them yield good results in different situations. "Do one thing..." is not the same as "do _only_ one thing..." and there are exceptions to the rules and _we_ made the rules so _we_ can/may change them. Sticking to rules when they don't make sense is stubbornness and locks one in a local maximum.
  - Annatar 10y ago
    Using a dedicated (de)compressor and then piping that as input to a tape archiver makes perfect sense to me: tar cf - file | xz -9evc > archive.tar.xz xz -dvc archive.tar.xz | tar xf -
- GFK_of_xmaspast 10y ago
  tar is a utility for creating and extracting .tar and .tgz files.
  - Annatar 10y ago
    No, gzip compressed tape archive has nothing to do with the tape archiver or the archiver format. Pipe the format to stdout without using compression and then it should be pretty obvious. This isn't Windows, Atari TOS or AmigaOS where archivers like pkzip and lha or lzx are also (de)compressors: that is precisely why on UNIX, gzip, compress, bzip2 or xz can only compress one single file and aren't archivers. They're dedicated (de)compressors. cpio, ar, pax and tar serve as dedicated archivers.
- GFK_of_xmaspast 10y ago
  If it's a tape archiver, why is it allowed to write to disk? Check and mate.
  - Annatar 10y ago
    tar isn't allowed or disallowed to write to disk -- f specifies a device, and that device just happens to be a file on a filesystem. Since everything on UNIX is a file, even a tape drive, even a huge 6,000 tape silo with 128 tape drives is multiple files under /dev/rmt/, this does not violate the principle. To put this into perspective for you, you could use the block device /dev/dsk/c0t0d0s2 as a tar file to write a tape archive to: tar cvf /some/path /dev/dsk/c0t0d0s2 The manual page for tar clearly states that tar is for tape archive manipulation: BSDTAR(1) BSD General Commands Manual BSDTAR(1) NAME tar -- manipulate tape archives Tape. Your statement is an indication that what you really need is to read AEleen Frisch's Essential System Administration so that the UNIX concepts would sink in, because if you're making such statements, you're just not there yet.
    - GFK_of_xmaspast 10y ago
      I've been using unix since 1992, starting with ultrix, then going to sunos, netbsd, solaris, linux, tru64, osx, and I think aix was in there somewhere too.
      - Annatar 10y ago
        But how much have you really learned? And were you an end user or a system administrator? I work with people who have used UNIX for 20-30 years and still don't understand why configuration packages should automatically (re)start a service upon upgrade, stop the service before removal, and start it upon initial install of the configuration package. 30 years of using all kinds of UNIX operating systems and they haven't learned a thing beyond being an end user. And some of these people are developers. So the length of usage isn't crucial, but how much one has learned about the subject -- with an understanding of concepts and ideas behind it. I used all of those you list -- but as my breadth and usage deepened, I sought to understand the principles and ideas behind UNIX.
- makomk 10y ago
  The -z option is just a more convenient way of piping the tarball through gzip at the appropriate time. GNU tar doesn't actually contain its own (de)compressor. You can also get it to use a compression program of your choice.

From the fact that tar is a tape archiver, and according to the UNIX philosophy of "do one thing and do it well" it should empathically not dub as a (de)compressor. GNU implements tools inside of other tools. Emacs is a perfect example if that.

qwertyuiop924 10y ago
GNU didn't originate from a unix mindset. You should know this. That doesn't mean their software is bad. Also, Emacs is incredibly useful, and one of the best general-purpose text editors out there.
- Annatar 10y ago
  GNU didn't originate from a unix mindset. You should know this. I do and oh-how-right you are. What I have major difficulty with is comprehending why people like it, and why they tolerate Stallman's nonsense when there are alternatives. The "rip it all out because it's not ours and re-invent everything just because" attitude is so fundamentale broken.
  - qwertyuiop924 10y ago
    As somebody who does tolerate Stallman's nonsense, I can tell you why: It's because some of his software is really good. Like Emacs. I'm willing to bet that you're a VI user, but for us Emacs users, there really is no substitute. And if you want a Scheme package, Guile is a really good one (although it's not as efficient as some of the compiled schemes): Andy is doing a great job with it. There are other examples, like tar (I know you would disagree, but dammit, GNU tar is so useful). When there isn't, or Stallman deliberately cripples his software, there are usually alternatives (clang, etc.) which we use, unless "we" are FSF people. Which most of us aren't. Yes, his attitude is somewhat broken, although I understand why it exists. Also, he's not quite as NIH as you seem to think: There are several cases where he advocates use of software that isn't his own (heck, he advocates clang, or at least has no problem with it). Also, I have no objection to long options, or to utilities that are a little bit richer (just so long as they still interoperate, and you can still use the standard options, which is usually the case).
    - Annatar 10y ago
      I'm willing to bet that you're a VI user, And you'd win that bet. Not even a vim user (except on Amiga), but straight vi. Why? Because vi was always there when I needed a text editor, and by learning vi, I automatically learned ed, sed, and ex. All of a sudden, I could write multi line sed programs.
      - qwertyuiop924 10y ago
        Hey, I get it. I've always have the sneaking suspicion that VI users are way more productive at actually editing. But I know for a fact that they don't have the extensions that make editing dynamic languages (especially lisp) in Emacs so efficient. And there's no use learning another editor just to write C: What do you think I am, and IDE user?
crististm 10y ago
In that case you mean option -x not -z. Either way, there are several philosophies and schools of thought. Many of them yield good results in different situations. "Do one thing..." is not the same as "do _only_ one thing..." and there are exceptions to the rules and _we_ made the rules so _we_ can/may change them. Sticking to rules when they don't make sense is stubbornness and locks one in a local maximum.
- Annatar 10y ago
  Using a dedicated (de)compressor and then piping that as input to a tape archiver makes perfect sense to me: tar cf - file | xz -9evc > archive.tar.xz xz -dvc archive.tar.xz | tar xf -
GFK_of_xmaspast 10y ago
tar is a utility for creating and extracting .tar and .tgz files.
- Annatar 10y ago
  No, gzip compressed tape archive has nothing to do with the tape archiver or the archiver format. Pipe the format to stdout without using compression and then it should be pretty obvious. This isn't Windows, Atari TOS or AmigaOS where archivers like pkzip and lha or lzx are also (de)compressors: that is precisely why on UNIX, gzip, compress, bzip2 or xz can only compress one single file and aren't archivers. They're dedicated (de)compressors. cpio, ar, pax and tar serve as dedicated archivers.
GFK_of_xmaspast 10y ago
If it's a tape archiver, why is it allowed to write to disk? Check and mate.
- Annatar 10y ago
  tar isn't allowed or disallowed to write to disk -- f specifies a device, and that device just happens to be a file on a filesystem. Since everything on UNIX is a file, even a tape drive, even a huge 6,000 tape silo with 128 tape drives is multiple files under /dev/rmt/, this does not violate the principle. To put this into perspective for you, you could use the block device /dev/dsk/c0t0d0s2 as a tar file to write a tape archive to: tar cvf /some/path /dev/dsk/c0t0d0s2 The manual page for tar clearly states that tar is for tape archive manipulation: BSDTAR(1) BSD General Commands Manual BSDTAR(1) NAME tar -- manipulate tape archives Tape. Your statement is an indication that what you really need is to read AEleen Frisch's Essential System Administration so that the UNIX concepts would sink in, because if you're making such statements, you're just not there yet.
  - GFK_of_xmaspast 10y ago
    I've been using unix since 1992, starting with ultrix, then going to sunos, netbsd, solaris, linux, tru64, osx, and I think aix was in there somewhere too.
    - Annatar 10y ago
      But how much have you really learned? And were you an end user or a system administrator? I work with people who have used UNIX for 20-30 years and still don't understand why configuration packages should automatically (re)start a service upon upgrade, stop the service before removal, and start it upon initial install of the configuration package. 30 years of using all kinds of UNIX operating systems and they haven't learned a thing beyond being an end user. And some of these people are developers. So the length of usage isn't crucial, but how much one has learned about the subject -- with an understanding of concepts and ideas behind it. I used all of those you list -- but as my breadth and usage deepened, I sought to understand the principles and ideas behind UNIX.
makomk 10y ago
The -z option is just a more convenient way of piping the tarball through gzip at the appropriate time. GNU tar doesn't actually contain its own (de)compressor. You can also get it to use a compression program of your choice.