The utility tar should rather be renamed to vtar. Why the heck does almost
everybody add the option
v automatically? Is that in any way helpful? Or
is it maybe even dangerous.
v belongs to tar like lice belong to your children's head, when
they come back from kindergarten. Omitting it makes the casual observer often
very nervous, and should something go wrong with the freshly installed
software, you will sometimes even hear the advice to untar the archive once
more, this time with
Almost every command line tool has an option
--verbose the purpose
of which is to overwrite unwanted output in the terminal window with utterly
useless and irrelevant data. But I do not know any other tool whose verbose
mode is so popular as tar's.
When asked why archive
xyz.tar.gz absolutely has to be unpacked with the
v, many people reply that they want to see what is contained in the
archive. So do I! And that is why I almost always list the contents of
a tarball with option
terminal but before I unpack it.
The next argument is: You want to see the progress of the action.
Sometimes, when I am really bored, I also want to see the progress of such
actions. But I am then interested in the ETA and depending on my degree of
boredom maybe also the percentage. Seeing some path names rush by in the
terminal window does not really look helpful to me with respect to progress
feedback. And, after all, I actually do see the progress. The least common
denominator of all shells is: When I don't see a prompt, something is going on.
And should I be irritated about the prompt not returning, I have the shell's
job control, i. e.
Short of more arguments, you will often hear that it is merely a matter of taste. After all, it doesn't hurt to make tar verbose.
But it does hurt! The only thing that we are interested in, when working with tar balls are possible errors, and exactly errors will get buried by tar's verbose output:
$ tar xzvf gimp-2.8.16.tar.gz ... gimp-2.8.16/themes/Default/images/stock-path-22.png gimp-2.8.16/themes/Default/images/stock-channel-indexed-16.png gimp-2.8.16/themes/Default/images/stock-channel-blue-32.png gimp-2.8.16/themes/Default/images/stock-quick-mask-on-12.png gimp-2.8.16/themes/Default/images/stock-gradient-bilinear-16.png gimp-2.8.16/themes/Default/images/stock-display-filter-gamma-16.png gimp-2.8.16/themes/Default/images/stock-texture-64.png gimp-2.8.16/themes/Default/images/stock-rotate-90-16.png gimp-2.8.16/themes/Default/images/stock-channel-gray-24.png gimp-2.8.16/themes/Default/images/stock-display-filter-16.png gimp-2.8.16/themes/Default/images/stock-gradient-spiral-clockwise-16.png gimp-2.8.16/themes/Default/images/stock-channel-alpha-32.png gimp-2.8.16/themes/Default/images/stock-channel-red-48.png tar: Exiting with failure status due to previous errors
Sure, after reading the above rant, everybody will spot the error message in
the last line. In reality that often will not happen, especially if the
archive is large and unpacking it takes a long time, in other words, exactly
when the option
v is considered useful by many people.
You should also not that this
summary in the last line is a GNU tar gimmick.
Other tar flavors just print errors on standard error wherever they occur,
and they will usually go completely unnoticed, unless you check the command's
exit code with
echo $?. But who does that?
This is not scaremongering. The tar of Sun Solaris used to have a ridiculously low limit on the length of path names. Installation tar balls of our software therefore had to be unpacked with GNU tar. Of course, a lot of people failed to follow our advice, and they also did not notice the error messages hidden between thousands of lines of output because Solaris' tar did not inform about the previously occurred errors at the end of its output.
Hence: The option
v for tar is completely useless!
blog comments powered by Disqus