On Wed, 26 Sep 2007 10:14:58 +0200, Alexander Skwar wrote: > Back to tar: Why use "tar -j" in scripts, when "bzip2 | tar" > does the same thing? I very much disagree that "tar -j" is > the "better" option here;
Either way requires that you first determine the type of compression used before you can decide where to pipe tar's output, if at all. Whereas something like "tar xf somefile" avoids the need to do" file somefile" and parse the output first. > in fact, I'd say that "bzip2 | tar" > is the better option, as it works on a lot more systems than > "tar -j" does. Heck, "tar -j" even does not work on all GNU > tar implementations, as very old GNU tars don't have bzip2 > support at all and -j wasn't always used for bzip2. If you don't know the details of the platform running your script, you should of course stick to POSIX, which tar can do fine. But if your script in running in an environment you control, why not make use of more efficient methods? > > POSIX > > specifies the minimum set of options and features, not the maximum. As > > long as the standards aren't broken, nothing is wrong, and adding new, > > useful and compatible features is one way that standards get > > improved. > > No, it's not. To improve a standard, you make sure that the standard > gets amended and then you implement something. Not the other way around. That's not how evolution works. Things are tried, some (most) fall by the wayside and others are accepted. As long as you don't break the standard with your enhancements, where's the harm in improvement? I know car analogies are tired, but it's like arguing that all cars should be designed to meet the minimum standards required by law, and if the law doesn't stipulate air conditioning, we don't need it - that example is usually true here in the UK :( -- Neil Bothwick The fact that no one understands you doesn't mean you're an artist.
signature.asc
Description: PGP signature
