5 ms·

This bums me out as well. One of the prime examples of this is tar: whenever someone says "extract this tarball", they usually give the command as this: tar

by OskarS 7y ago

This bums me out as well. One of the prime examples of this is tar: whenever someone says "extract this tarball", they usually give the command as this: tar xfvz my-source-code.1.2.3.tar.gz What does those flags mean? Who knows! I mean, I know because I've used it enough, but for many people those are just a mysterious incantation (there's even an xkcd about it! [0]) The reason is arguably that tar has too many responsibilities here. Tar should only do two things: create tar streams and extract tar streams into files. You do that with "tar c" and "tar x", and that's everything you should need to remember (ok, fine, "tar t" for listing files is good to know as well). Commands to create tarballs should look like this: tar c directory | gzip > directory.tar.gz And untar commands should look like this: zcat directory.tar.gz | tar x or maybe cat directory.tar.gz | gunzip | tar x or whatever version you prefer with "tar x" at the end. This is composable, super-easy to remember, and you can VERY easily swap out any parts for any other parts (for instance, changing the source from a file to a url with curl, or the destination for an ssh pipe or something). One of the benefits of the "swapping out" parts are of course that you're not restricted to what's built into tar: you can use ANY compression utility you want. For instance, there's a thing called pigz[1] which parallelizes gzip decompression for increased speed. It's trivial to swap into the pipeline when you use tar that way: cat directory.tar.gz | unpigz | tar x Congratulations, you now have much faster expansion of tarballs, without needing to recompile tar. We've taught a generation of programmers that "tar" is hard to use and you have to look up a magic incantation every time you need it. Ironically, that makes tar less flexible, because now you think of it as a single-purpose utility (creating and unpacking compressed tarballs) instead of a versatile unix tool which can be used in all sorts of different situations. [0]: https://xkcd.com/1168/ https://xkcd.com/1168/ [1]: https://zlib.net/pigz/ https://zlib.net/pigz/

kanox 7y ago
> tar xfvz my-source-code.1.2.3.tar.gz Modern tar can detect the format so "tar xfv" is enough. The "v" option only means "verbose" so it's better just "tar xf" and avoid spamming the terminal.
- jandrese 7y ago
  I always use -v because every so often I find a tarball that was taken from inside of the working directory instead of outside. Of course these days it's not humanly possible to ctrl-c it before it extracts thousands of files and makes cleanup a chore but at least you won't be confused as to what happened when you attempt to cd into the directory later. For that matter knowing what directory to cd into is also a good reason to use -v. Note: If none of your files were clobbered and there are no spaces in the filenames to worry about you can do: tar -tf [tarball] | xargs rm -d Run it repeatedly if you also want to remove the directories.
intrepidhero 7y ago
If I want to untar a file, odds are I also want to decompress it so I like having both features in one tool. That said I also really appreciate your composable approach. I wish my early unix education had leaned in pipes a lot harder. But what I came here to say is that I find the typical tar flags pretty intuitive. X means extract, z means using zip/unzip, v means verbose, and f for file I/O instead of stdin/stdout. For typical use cases, I don't find its interface magical but logical. I'll freely admit to needing 'man tar' anytime I stray from the typical use, but that's true of a lot of commands. The bigger offender in my mind is rsync. I remember auvP as my typical flags but don't ask me what they do. And good luck guessing whether my destination or source path need a trailing slash on the first try...
- OskarS 7y ago
  Yeah, it's true, rsync is a real nightmare when it comes to arguments. I remember reading that xkcd comic though and I went "yup, that's me!", and I've spent a bunch of time thinking about why that was. You list those flags there and say there intuitive, but they're unique to tar, you have to memorize them, and there's no reason that they need to be in tar when they're available right there in the shell. Why do I need to memorize that the "f" flag is "file output/input", when I can just write "> dest-file" or "cat src-file |" (or "< src-file") in my shell? That works for every command, not just tar. Why do I need to remember that the z file is for gzip (what's the equivalent flag for bzip2?) when gzip/gunzip exists and works for anything? So many people simply don't understand what tar does or how to use it without googling the magic formula they need, and it's because of all these damn flags that everyone insists on using instead of doing it the "unix way".
  - jandrese 7y ago
    Backwards compatibility is a bitch mostly. Tar defaults to using the tape drive because that's what it was originally designed to do. Using it to create file archives was a hack added later, but nobody wanted to break backwards compatibility with old backup scripts by changing its defaults, so we're stuck with its oddball syntax today. dd is another program where the commandline flags predate modern usage (although it does at least behave nicely with pipes by default) and look totally weird compared to everything else. But again nobody wants to touch them because it would break millions of existing scripts.
eMSF 7y ago
>I mean, I know because I've used it enough Perhaps you mean that you've looked it up. Others could do so, too; it's not that hard (even if a web comic makes light-hearted fun of the subject)! Anyway, here's a fun fact: tar is smarter than you give it credit. The commands below do just work: tar xf uncompressed.tar tar xf gzipped.tar.gz tar xf xzipped.tar.xz
- OskarS 7y ago
  That's true, and it's nice that it works, but it's just more magic information you have to memorize about tar. And it works one way but not the other. What is the flag for creating the archive compressed with bzip2? Without looking it up? I have no idea. "b" maybe? Does the file name come before the folder name, or is it vice versa? Who knows. How about: tar c folder | bzip2 > folder.tar.bz2 I didn't have to look any of that up.
  - eMSF 7y ago
    The file name's position is not magical; it's linked to the -f flag. tar -c [files...] -f archive.tar The thing is, for both basic compressing and decompressing you don't actually have to memorize all that much: tar xf archive.tar.gz # to uncompress tar caf archive.tar.ext [files...] # to compress (One could argue that for symmetry you might want to use xaf instead of xf.)
chubot 7y ago
You're not alone, I Just wrote essentially the same thing here :) https://news.ycombinator.com/item?id=22478692 https://news.ycombinator.com/item?id=22478692

by OskarS 7y ago

kanox 7y ago

> tar xfvz my-source-code.1.2.3.tar.gz Modern tar can detect the format so "tar xfv" is enough. The "v" option only means "verbose" so it's better just "tar xf" and avoid spamming the terminal.

jandrese 7y ago
I always use -v because every so often I find a tarball that was taken from inside of the working directory instead of outside. Of course these days it's not humanly possible to ctrl-c it before it extracts thousands of files and makes cleanup a chore but at least you won't be confused as to what happened when you attempt to cd into the directory later. For that matter knowing what directory to cd into is also a good reason to use -v. Note: If none of your files were clobbered and there are no spaces in the filenames to worry about you can do: tar -tf [tarball] | xargs rm -d Run it repeatedly if you also want to remove the directories.

intrepidhero 7y ago

If I want to untar a file, odds are I also want to decompress it so I like having both features in one tool. That said I also really appreciate your composable approach. I wish my early unix education had leaned in pipes a lot harder. But what I came here to say is that I find the typical tar flags pretty intuitive. X means extract, z means using zip/unzip, v means verbose, and f for file I/O instead of stdin/stdout. For typical use cases, I don't find its interface magical but logical. I'll freely admit to needing 'man tar' anytime I stray from the typical use, but that's true of a lot of commands. The bigger offender in my mind is rsync. I remember auvP as my typical flags but don't ask me what they do. And good luck guessing whether my destination or source path need a trailing slash on the first try...

OskarS 7y ago
Yeah, it's true, rsync is a real nightmare when it comes to arguments. I remember reading that xkcd comic though and I went "yup, that's me!", and I've spent a bunch of time thinking about why that was. You list those flags there and say there intuitive, but they're unique to tar, you have to memorize them, and there's no reason that they need to be in tar when they're available right there in the shell. Why do I need to memorize that the "f" flag is "file output/input", when I can just write "> dest-file" or "cat src-file |" (or "< src-file") in my shell? That works for every command, not just tar. Why do I need to remember that the z file is for gzip (what's the equivalent flag for bzip2?) when gzip/gunzip exists and works for anything? So many people simply don't understand what tar does or how to use it without googling the magic formula they need, and it's because of all these damn flags that everyone insists on using instead of doing it the "unix way".
- jandrese 7y ago
  Backwards compatibility is a bitch mostly. Tar defaults to using the tape drive because that's what it was originally designed to do. Using it to create file archives was a hack added later, but nobody wanted to break backwards compatibility with old backup scripts by changing its defaults, so we're stuck with its oddball syntax today. dd is another program where the commandline flags predate modern usage (although it does at least behave nicely with pipes by default) and look totally weird compared to everything else. But again nobody wants to touch them because it would break millions of existing scripts.

eMSF 7y ago

>I mean, I know because I've used it enough Perhaps you mean that you've looked it up. Others could do so, too; it's not that hard (even if a web comic makes light-hearted fun of the subject)! Anyway, here's a fun fact: tar is smarter than you give it credit. The commands below do just work: tar xf uncompressed.tar tar xf gzipped.tar.gz tar xf xzipped.tar.xz

OskarS 7y ago
That's true, and it's nice that it works, but it's just more magic information you have to memorize about tar. And it works one way but not the other. What is the flag for creating the archive compressed with bzip2? Without looking it up? I have no idea. "b" maybe? Does the file name come before the folder name, or is it vice versa? Who knows. How about: tar c folder | bzip2 > folder.tar.bz2 I didn't have to look any of that up.
- eMSF 7y ago
  The file name's position is not magical; it's linked to the -f flag. tar -c [files...] -f archive.tar The thing is, for both basic compressing and decompressing you don't actually have to memorize all that much: tar xf archive.tar.gz # to uncompress tar caf archive.tar.ext [files...] # to compress (One could argue that for symmetry you might want to use xaf instead of xf.)

chubot 7y ago

You're not alone, I Just wrote essentially the same thing here :) https://news.ycombinator.com/item?id=22478692 https://news.ycombinator.com/item?id=22478692