Tar Option 'v' Considered Harmful

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.

The option 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 tar xv.

Almost every command line tool has an option -v or --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 option 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 t like 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. CTRL-C, CTRL-Z.

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!