never seen that in my life until now - what does it do? Just unzip the file to dev/null? What's the purpose? Does the verbose flag show you what's inside but the dev/null means it's not written to disk while unzipping?
Actually, the files are decompressed to the current directory, it's the just output of the verbose flag that goes to /dev/null. Which makes is even more senseless.
Exactly. I've seen people who always do `tar xzvf` and have no idea removing the `v` is the correct way to make it not print the name of every file in the archive.
You didn't use to be able to suppress the 'z' switch. You had to specify 'z' or 'j' depending on whether you wanted gzip or bzip2 decompression. It's a somewhat recent (sometime in the last 15 years, I think) change to "tar" to make it just detect the compression algorithm.
Isn't it better though to omit the -v switch and do `ls *` and/or `tree` afterwards? That gives you the same information but structured so it's much easier to understand.
The advantage of -v is that you can see what is being extracted as it happens. This is useful if you have a tarball with thousands of small files, as otherwise it's hard to tell whether tar has got stuck or there are just a lot of files.
$ tar -xf foo.tar.xz
tar: End of archive volume 1 reached
tar: input compressed with xz
$ tar -xf foo.tar.gz
tar: End of archive volume 1 reached
tar: input compressed with gzip; use the -z option to decompress it
It tells you how it's compressed and how to decompress it if it knows how. OpenBSD's tar doesn't support xz so it can't help there, but does support gzip so it suggests using -z.
Not letting untrusted input automatically increase the attack surface it's exposed to is a feature.
>Not letting untrusted input automatically increase the attack surface it's exposed to is a feature.
How is that a feature? The user's explicitly asking for this.
This feature reminds me of vim, that suggests closing with ":quit" when you press C-x C-c (i.e. the keychord to close emacs). It knows full well what you want to do and even has special code to handle it, but then insists to hand you more work.
Vim suggests closing with ":quit" when you hit C-c; the C-x is irrelevant.
Upon receiving a C-c, it does not know full well what the user wants to do.
When vim receives a C-c from you (or someone who just stumbled into vim and doesn't know how to exit) the user wants to exit.
When vim receives a C-c from me, it's because I meant to kill the process I spawned from vim, and it ended before the key was pressed. I very much do not want it to quit on me at that point.
`tar -xf` is not "explicitly asking" for gzip. `tar -zxf` is "explicitly asking" for gzip.
I don't really care what vim does, that's a different argument. There have been many vulnerabilities in gzip, and in tar implementations that let untrusted input choose how it gets parsed, those vulnerabilities might as well be in tar itself.
