7 ms·

Why is it so difficult to write valid “tar” commands from memory?

15 points by FreakyT 12y ago

tiagocesar 12y ago
I hope I wasn't the only one mouse hovering the XKCD image that appears in the RSS reader (Feedly here) to see its actual ALT.
- DanAndersen 12y ago
  Hate to post "me too," but I did the exact same thing.
opless 12y ago
Difficult? I don't see how it's difficult. Are [li|u]nix admins getting more stupid?
- FreakyT 12y ago
  I figure the relevant XKCD[1] wouldn't exist if this weren't the case. [1] https://xkcd.com/1168/ https://xkcd.com/1168/
  - astrodust 12y ago
    Snarky and sarcastic. Honestly, tar is the least hard "hard" thing you'll encounter in the UNIX world. How about writing a valid firewalld configuration command to open port 8060 TCP and UDP to connections from 10.0.0.0/8 and have it saved and applied immediately.
- matrixagent 12y ago
  linix admins?
  - opless 12y ago
    well spotted ;)
dvh 12y ago
tar c * > ../foo.tar; gzip ../foo.tar (you don't need anything else)
- rascul 12y ago
  tar czf ../foo.tar.gz * (GNU tar can do it all in one command)
  - feld 12y ago
    Both of you are creating a tarbomb and should be ashamed http://en.wikipedia.org/wiki/Tar_%28computing%29#Tarbomb http://en.wikipedia.org/wiki/Tar_%28computing%29#Tarbomb
    - rascul 12y ago
      I agree, but that's how the original was
  - LukeShu 12y ago
    I think OP's point is that instead of learning the options of tar, you can just learn the basics, and use unix composibility to do the more complex things without learning more.
- belovedeagle 12y ago
  A significant improvement is to instead use tar -c files | gzip > ../foo.tgz No messing around with flags, just a single one saying that you want to create an archive rather than extract one. No messing around with filename parameters—that's what the shell is there for.
zcdziura 12y ago
99 times out of 100, I'm extracting a gzip'd tarball. Thus, I've muscle-memorized "tar xzf file.tar.gz". What helped me do that was a little mnemonic that my friend told me: eXtract Zee File.
- rascul 12y ago
  GNU tar can figure out how to decompress it on its own. Just xf will do.
- iagooar 12y ago
  Just read your answer after writing mine, have been using the same one, adding a German touch to it ;)
- robgibbons 12y ago
  This is hilarious, memorable, and actually useful. Thank you zcdziura, may the wind be at your back.
dalke 12y ago
If the thesis were correct then 'zip', which has the arguments in the same order as tar, would also have the same issues. For example, to add/update an entry in a zip file, do: zip test.zip test/test.txt I have not heard of the zip command-line as being more or equally frustrating than tar, so I do not believe this thesis is correct.
- FreakyT 12y ago
  That's a good point, though I feel like that may just arise from 'zip' being the less commonly encountered of the two utilities.
  - dalke 12y ago
    I am unable to compare the number of Windows-based developers, who often use zip as an archive format, and Java-based developers, who often use zip to work with jar files, to the number of people who use tar. My guess is that tar users would be in the minority. How did you come to the conclusion about which is most commonly encountered? Also, other popular archivers also use the archive-first approach: 7z.exe a c:\a.7z file1.txt dir2\file2.txt rar a -r yourfiles.rar *.txt c:\yourfolder
    - dagw 12y ago
      zip is almost certainly the most used archive format, but that doesn't mean the the 'zip' command line tool is more used than the 'tar' command line tool. Even though I've probably run across more .zip files than .tar files (and certainly more archives of in the zip format) in my career, if undoubtedly typed 't-a-r' on a command line many more times than 'z-i-p'.
      - dalke 12y ago
        Oh, I certainly use tar more than zip. My downloads directory has 67 tar files and 15 zip files. Bear in mind though that the hypothesis is not specific to Unix development. The examples are: cp file1.txt file2.txt file3.txt destination/ mv file1.txt file2.txt file3.txt destination/ The equivalent in MS Windows command shell is: copy file1.txt file2.txt file3.txt destination\ move file1.txt file2.txt file3.txt destination\ The hypothesis makes the prediction that Windows command-line users (which is a subset of all Windows users) will have similar problems with zip/7zip/rar's "inverted" command-line parameters. Similarly, the hypothesis predicts that people who use the command-line to work regularly with .jar, .odf, and other zip-based file formats will also have problem with the ordering. I have not heard of such problems, but I am not knowledgeable about those areas of development.
informatimago 12y ago
This is riduculous. There's no difficulty writing tar commands. Just RTFM: man tar; I've written tar commands for 30 years: on day 0 I read the manual page, and since day 1 I've been writing tar commands without any problem. (Same with find: first time a friend hacker dictated me a find command, next step I read the manual and since then I've been a happy find user). The secret of unix diffusion has been its man pages, full documentation of your local unix system, specific and always available on-line (even when the network is disconnected). Nowdays, with google or stackoverflow, you have the big problem that the documentation you get doesn't necessarily (probably never) match your specific installation, when you search for documentation, and that you get more fishes than fishing lessons.
soneil 12y ago
I think it gets easier once you internalize that your destination filename is actually an option to -f. it's not tar czf (filename) (list of files). it's tar cz(f filename) list of files. Ironically, I think it'd actually be more intuitive if we used the options fully; tar -c -f filename -z (list of files). But we end up memorizing shorthand before we know what it means, rather than after.
lotsofcows 12y ago
What? You stick switch parameters after the switches and general parameters on the end just like every other sensible command. "tar cf"? "cf"? There's your problem! If you follow the anachronistic "bundled flags" approach no wonder you're getting it wrong. "tar -c -f <parm>"!
facepalm 12y ago
Why do I need flags to begin with? tar and untar would have worked fine.
- cstoner 12y ago
  Because originally tar only dealt with tape archives. So the default behavior was (and still is [EDIT: correction, apparently a lot of GNU tar distributions have defaulted to using -f- which sends things to stdout. That is not how tar originally functioned]) to send the results to /dev/st tar was later changed to read/extract(-x) and write/create(-c) from files(-f). And was also modified to handle gzip(-z) and bzip2(-j) compression. Essentially, the problem comes down to having to support all of the old scripts that depend on default tar behavior, even though people rarely write to tape drives with it any more.
- bydo 12y ago
  Unar is pretty good. Saves a letter, even. http://unarchiver.c3.cx/commandline http://unarchiver.c3.cx/commandline
jakupovic 12y ago
I think that the destination comes first as then you're free to tack on any number additional files to add to the archive by simply appending them. If the destination was last argument any added files would have to come before the destination which would necessitate an insert, which is more work than a simple append.
dgomez1092 12y ago
Maybe I agree with facepalm. But also with informatimago down at the bottom. It's probably be in my best interest to read most unix commands straight from man. I tend to use tar -czf <file> to untar. If it didn't work I'd proceed to tar -xzf <file> or tar xzf <file>. Even so sometime my machine wouldn't accept the command until I tried something like untar (not real!) or unzip or gzip. But those were mostly out of frustration.
joshbaptiste 12y ago
Tar is OK but for scripting and/or archiving over socket connections find(1) with pax(1) rules.. http://www.bash-hackers.org/wiki/doku.php/howto/pax http://www.bash-hackers.org/wiki/doku.php/howto/pax
LukeShu 12y ago
A couple of nits: - TFA says that `ln` is "used to create symbolic links, among other things"; I'd drop "symbolic"--that is needlessly restricting what it does. It just creates filesystem links; hard or soft. - TFA says, "tar is actually short for TApe aRchive". The "a" should belong to "archive" ("Tape ARchive"); this is because of it's relation to the older `ar` ("ARchive") command.[^1] - TFA says, "the filename is actually part of the f flag, and therefore must directly follow it." That's actually not the case for the "dash-less" form of tar invocation; all of the flags go in one string, and then the arguments follow in the same order, rather than right after the associated flag. For example, if I wanted to specify both the "f" and "C" flags, it (c|w)ould be something like `tar cfC argument-to-f argument-to-C`. That said, modern tars also support `tar -c -f argument-to-f -C argument-to-C`. As TFA says, this isn't inherently wrong, it's just different than everything else (I know of no other command that uses that flag syntax[^2]). Understand that it predates the standard convention that everything else follows. [^1]: Today ar is pretty much only used for creating .a files containing library objects for static linking. It may be noteworthy that the argument order of ar is ALSO "archive-name members..." despite archive-name NOT being an argument to an "-f"-like flag. [^2]: Actually, come to think of it, `ps` might take that syntax, depending on your system.
- FreakyT 12y ago
  Great points! I've made some minor edits to the article to reflect them: * Description of "ln" is more general * "Tape ARchive" is now described correctly * No longer uses the arguments in "dash-less" mode
- Domenic_S 12y ago
  I don't like ln as an example of sanity. $ ln usage: ln [-Ffhinsv] source_file [target_file] ln [-Ffhinsv] source_file ... target_dir "Source = from", "target = to" is how I interpret that. Then if you look at some existing link, you'll see it as: my_link --> real_directory In the direction of the arrow: from, to. But to create that link, the command would really be $ ln real_directory my_link The link target/real path is the source and the link to create is the target. My brain thinks it breaks the idiom of `[cmd] [from] [to]` that cp, mv, etc use. You wouldn't say the example above is a link from real_dir to my_link, you'd say the opposite (and that's what the cli shows when you ls a link).
tw04 12y ago
>Naturally, tar is never really used in this way anymore. I think Veritas and their thousands customers would beg to differ.
iagooar 12y ago
For some years now I have been using a quite funny mnemonic in order to remember how to extract a gzipped tar. It reads "eXtract Ze File" with German accent ;)
tavein 12y ago
It's hard and it has rather old interface (not a bad one, just old). Recently I've switched to patool (http://wummel.github.io/patool/ http://wummel.github.io/patool/) and quite happy with it.

15 points by FreakyT 12y ago

I hope I wasn't the only one mouse hovering the XKCD image that appears in the RSS reader (Feedly here) to see its actual ALT.

DanAndersen 12y ago
Hate to post "me too," but I did the exact same thing.

opless 12y ago

Difficult? I don't see how it's difficult. Are [li|u]nix admins getting more stupid?

FreakyT 12y ago
I figure the relevant XKCD[1] wouldn't exist if this weren't the case. [1] https://xkcd.com/1168/ https://xkcd.com/1168/
- astrodust 12y ago
  Snarky and sarcastic. Honestly, tar is the least hard "hard" thing you'll encounter in the UNIX world. How about writing a valid firewalld configuration command to open port 8060 TCP and UDP to connections from 10.0.0.0/8 and have it saved and applied immediately.
matrixagent 12y ago
linix admins?
- opless 12y ago
  well spotted ;)

dvh 12y ago

tar c * > ../foo.tar; gzip ../foo.tar (you don't need anything else)

rascul 12y ago
tar czf ../foo.tar.gz * (GNU tar can do it all in one command)
- feld 12y ago
  Both of you are creating a tarbomb and should be ashamed http://en.wikipedia.org/wiki/Tar_%28computing%29#Tarbomb http://en.wikipedia.org/wiki/Tar_%28computing%29#Tarbomb
  - rascul 12y ago
    I agree, but that's how the original was
- LukeShu 12y ago
  I think OP's point is that instead of learning the options of tar, you can just learn the basics, and use unix composibility to do the more complex things without learning more.
belovedeagle 12y ago
A significant improvement is to instead use tar -c files | gzip > ../foo.tgz No messing around with flags, just a single one saying that you want to create an archive rather than extract one. No messing around with filename parameters—that's what the shell is there for.

zcdziura 12y ago

99 times out of 100, I'm extracting a gzip'd tarball. Thus, I've muscle-memorized "tar xzf file.tar.gz". What helped me do that was a little mnemonic that my friend told me: eXtract Zee File.

rascul 12y ago
GNU tar can figure out how to decompress it on its own. Just xf will do.
iagooar 12y ago
Just read your answer after writing mine, have been using the same one, adding a German touch to it ;)
robgibbons 12y ago
This is hilarious, memorable, and actually useful. Thank you zcdziura, may the wind be at your back.

dalke 12y ago

If the thesis were correct then 'zip', which has the arguments in the same order as tar, would also have the same issues. For example, to add/update an entry in a zip file, do: zip test.zip test/test.txt I have not heard of the zip command-line as being more or equally frustrating than tar, so I do not believe this thesis is correct.

FreakyT 12y ago
That's a good point, though I feel like that may just arise from 'zip' being the less commonly encountered of the two utilities.
- dalke 12y ago
  I am unable to compare the number of Windows-based developers, who often use zip as an archive format, and Java-based developers, who often use zip to work with jar files, to the number of people who use tar. My guess is that tar users would be in the minority. How did you come to the conclusion about which is most commonly encountered? Also, other popular archivers also use the archive-first approach: 7z.exe a c:\a.7z file1.txt dir2\file2.txt rar a -r yourfiles.rar *.txt c:\yourfolder
  - dagw 12y ago
    zip is almost certainly the most used archive format, but that doesn't mean the the 'zip' command line tool is more used than the 'tar' command line tool. Even though I've probably run across more .zip files than .tar files (and certainly more archives of in the zip format) in my career, if undoubtedly typed 't-a-r' on a command line many more times than 'z-i-p'.
    - dalke 12y ago
      Oh, I certainly use tar more than zip. My downloads directory has 67 tar files and 15 zip files. Bear in mind though that the hypothesis is not specific to Unix development. The examples are: cp file1.txt file2.txt file3.txt destination/ mv file1.txt file2.txt file3.txt destination/ The equivalent in MS Windows command shell is: copy file1.txt file2.txt file3.txt destination\ move file1.txt file2.txt file3.txt destination\ The hypothesis makes the prediction that Windows command-line users (which is a subset of all Windows users) will have similar problems with zip/7zip/rar's "inverted" command-line parameters. Similarly, the hypothesis predicts that people who use the command-line to work regularly with .jar, .odf, and other zip-based file formats will also have problem with the ordering. I have not heard of such problems, but I am not knowledgeable about those areas of development.

informatimago 12y ago

This is riduculous. There's no difficulty writing tar commands. Just RTFM: man tar; I've written tar commands for 30 years: on day 0 I read the manual page, and since day 1 I've been writing tar commands without any problem. (Same with find: first time a friend hacker dictated me a find command, next step I read the manual and since then I've been a happy find user). The secret of unix diffusion has been its man pages, full documentation of your local unix system, specific and always available on-line (even when the network is disconnected). Nowdays, with google or stackoverflow, you have the big problem that the documentation you get doesn't necessarily (probably never) match your specific installation, when you search for documentation, and that you get more fishes than fishing lessons.

soneil 12y ago

I think it gets easier once you internalize that your destination filename is actually an option to -f. it's not tar czf (filename) (list of files). it's tar cz(f filename) list of files. Ironically, I think it'd actually be more intuitive if we used the options fully; tar -c -f filename -z (list of files). But we end up memorizing shorthand before we know what it means, rather than after.

lotsofcows 12y ago

What? You stick switch parameters after the switches and general parameters on the end just like every other sensible command. "tar cf"? "cf"? There's your problem! If you follow the anachronistic "bundled flags" approach no wonder you're getting it wrong. "tar -c -f <parm>"!

facepalm 12y ago

Why do I need flags to begin with? tar and untar would have worked fine.

cstoner 12y ago
Because originally tar only dealt with tape archives. So the default behavior was (and still is [EDIT: correction, apparently a lot of GNU tar distributions have defaulted to using -f- which sends things to stdout. That is not how tar originally functioned]) to send the results to /dev/st tar was later changed to read/extract(-x) and write/create(-c) from files(-f). And was also modified to handle gzip(-z) and bzip2(-j) compression. Essentially, the problem comes down to having to support all of the old scripts that depend on default tar behavior, even though people rarely write to tape drives with it any more.
bydo 12y ago
Unar is pretty good. Saves a letter, even. http://unarchiver.c3.cx/commandline http://unarchiver.c3.cx/commandline

jakupovic 12y ago

I think that the destination comes first as then you're free to tack on any number additional files to add to the archive by simply appending them. If the destination was last argument any added files would have to come before the destination which would necessitate an insert, which is more work than a simple append.

dgomez1092 12y ago

Maybe I agree with facepalm. But also with informatimago down at the bottom. It's probably be in my best interest to read most unix commands straight from man. I tend to use tar -czf <file> to untar. If it didn't work I'd proceed to tar -xzf <file> or tar xzf <file>. Even so sometime my machine wouldn't accept the command until I tried something like untar (not real!) or unzip or gzip. But those were mostly out of frustration.

joshbaptiste 12y ago

Tar is OK but for scripting and/or archiving over socket connections find(1) with pax(1) rules.. http://www.bash-hackers.org/wiki/doku.php/howto/pax http://www.bash-hackers.org/wiki/doku.php/howto/pax

LukeShu 12y ago

A couple of nits: - TFA says that `ln` is "used to create symbolic links, among other things"; I'd drop "symbolic"--that is needlessly restricting what it does. It just creates filesystem links; hard or soft. - TFA says, "tar is actually short for TApe aRchive". The "a" should belong to "archive" ("Tape ARchive"); this is because of it's relation to the older `ar` ("ARchive") command.[^1] - TFA says, "the filename is actually part of the f flag, and therefore must directly follow it." That's actually not the case for the "dash-less" form of tar invocation; all of the flags go in one string, and then the arguments follow in the same order, rather than right after the associated flag. For example, if I wanted to specify both the "f" and "C" flags, it (c|w)ould be something like `tar cfC argument-to-f argument-to-C`. That said, modern tars also support `tar -c -f argument-to-f -C argument-to-C`. As TFA says, this isn't inherently wrong, it's just different than everything else (I know of no other command that uses that flag syntax[^2]). Understand that it predates the standard convention that everything else follows. [^1]: Today ar is pretty much only used for creating .a files containing library objects for static linking. It may be noteworthy that the argument order of ar is ALSO "archive-name members..." despite archive-name NOT being an argument to an "-f"-like flag. [^2]: Actually, come to think of it, `ps` might take that syntax, depending on your system.

FreakyT 12y ago
Great points! I've made some minor edits to the article to reflect them: * Description of "ln" is more general * "Tape ARchive" is now described correctly * No longer uses the arguments in "dash-less" mode
Domenic_S 12y ago
I don't like ln as an example of sanity. $ ln usage: ln [-Ffhinsv] source_file [target_file] ln [-Ffhinsv] source_file ... target_dir "Source = from", "target = to" is how I interpret that. Then if you look at some existing link, you'll see it as: my_link --> real_directory In the direction of the arrow: from, to. But to create that link, the command would really be $ ln real_directory my_link The link target/real path is the source and the link to create is the target. My brain thinks it breaks the idiom of `[cmd] [from] [to]` that cp, mv, etc use. You wouldn't say the example above is a link from real_dir to my_link, you'd say the opposite (and that's what the cli shows when you ls a link).

tw04 12y ago

>Naturally, tar is never really used in this way anymore. I think Veritas and their thousands customers would beg to differ.

iagooar 12y ago

For some years now I have been using a quite funny mnemonic in order to remember how to extract a gzipped tar. It reads "eXtract Ze File" with German accent ;)

tavein 12y ago

It's hard and it has rather old interface (not a bad one, just old). Recently I've switched to patool (http://wummel.github.io/patool/ http://wummel.github.io/patool/) and quite happy with it.