Hacker News Reader

Comment by reacweb | Hacker News Reader

In my project, I maintain 3 documents. The first one is a similar list of basic linux knowledge that people should learn when arriving on the project. The second is "UnixTipsAndPitfalls" where people should add new entries when they encounter usefull commands. The third one is about tar.

View on HN

Over years I've heard a lot of complains on tar being hard to use, but in real-life I really ever had to use only these two commands: tar zcvf and tar zxvf. It's actually quite easy to remember: tar Zip Compress Verbose File, and tar Zip eXtract Verbose File.

It's even easier than that! Less memorization, more understanding.

You can think of Tar arguments as either subcommands or options. The dashes are optional

The "subcommands" are x (extract), c (create), t (list), among others.

The "options" are f (read from named file rather than stdin), v (verbose mode), and z (run gzip on the archive before processing).

The fact that these options can be written without leading dashes, and all smashed together in a single argument, is legacy silliness for saving a few keystrokes. Don't confuse yourself with it, and don't confuse other people by teaching it to them, instead of teaching them how to actually use the command (which is really not hard at all).

So when I write Tar commands, I like to think along these lines. Instead of "tar zcvf foo.tar.gz", I write "tar -c -zv -f foo.tar.gz". After doing that about 3 times, it all sank in. Nowadays I'm much more intimidated by Git than Tar.

In the version of tar on the machine I'm posting from (GNU tar 1.27.1), this structure is obvious from right there in the man page:

    SYNOPSIS
       Traditional usage
           tar {A|c|d|r|t|u|x}[GnSkUWOmpsMBiajJzZhPlRvwo] [ARG...]
    
       UNIX-style usage
           tar -A [OPTIONS] ARCHIVE ARCHIVE

           tar -c [-f ARCHIVE] [OPTIONS] [FILE...]

           tar -d [-f ARCHIVE] [OPTIONS] [FILE...]

           tar -t [-f ARCHIVE] [OPTIONS] [MEMBER...]

           tar -r [-f ARCHIVE] [OPTIONS] [FILE...]

           tar -u [-f ARCHIVE] [OPTIONS] [FILE...]

           tar -x [-f ARCHIVE] [OPTIONS] [MEMBER...]

Thank you! That was very useful

Also -j for un-bzip2-ing which comes useful quite often.

You can just do `tar caf` and `tar xaf`. It detects the archive format automatically (and I personnally find it easier to remember: "compress-as-fuck" and "extract-as-fuck").

wow thanks for that :)

Yes. I also suggest to use tar instead of the dangerous cp -r: tar c -C src . | tar x -C dst.

It works over ssh connections (ssh -C for compression) and is a good training of tar syntax.

It is also quite slow.

For such moves rsync works much better.

Over years I've heard a lot of complaints on tar being hard to use, but in real-life I really ever had to use only these two commands: zip and unzip. It's actually quite easy to remember: zip, and unzip.

add 'tar r' and 'tar u' to your arsenal.

In about 40 years of using Unix I have never used r or u.

both seem fairly important in the 40-years-ago world concerning the 't'(ape) part of tar but okay.

I use them frequently as an "rsync"-ish into the archive file, which I can then use to take point-in-time snapshot/backups.

> The third one is about tar.

Why do people have such a difficult time with tar? The only tar commands I've ever needed (or seen other people need) are `tar cf ...` or `tar xf ...` (occasionally I'll need to chuck a z in there if the file is/needs to be gzipped), are other people just using far more complex tar commands than I am?

Because people assume they should RTM and if memory serves me right it is a whole lot more confusing than your post :-)

Doesn't look any more complex than most man pages: https://linux.die.net/man/1/tar

Part of my point: most of them are complex and to a big degree unnecessarily complex.

I agree and wish distro maintainers could make some changes. I would love to use manual pages, but instead I search the Internet first. If every manual had a section with most-common examples, it would help immensely. You could just type 'manexamples tar' and it would print out

tar cvf somedir filename.tar create an archive from somedir and store it in filename.tar

tar xvpf filename.tar extract the contents of filename.tar and scatter them around your home directory

Instead of getting examples that I might use, when I visit a man page, I get a wall of text 926 lines long, describing every possible option, including GNU option styles, or some truncated mess telling me to read the info pages.

Of course, it's appropriate that all this information is included somewhere in the manual. I just think the common use cases should be first. Does anyone need a man page for 'ls' that starts off describing how to list inode numbers and SELinux labels?

It's sort of embarrassing how much less efficient man pages are than a Google search to a SO question.

The justification I usually hear is that SO is for learning to solve one case, while man pages are for learning how the tool works. There's some merit to that, but if a tool has some hidden gotcha or unusual use, SO tends to make that much clearer than the actual documentation.

I suppose comprehensiveness was a higher priority when there wasn't an online discussion of every imaginable case, but it still feels like a lot could be done to convey the same amount of information more gracefully.

I'd love to get a man page like that but all too often they don't list examples near the top like that. If I open the tar man page for cygwin (probably an older one) I get a bunch of stuff about unix style and gnu style usage, then some irrelevant notes (where the full manual is), then a long winded description about how "tar -xvf" is the same as "tar -x -v -f", then the full descriptions of each option.

It sounds like this project moved in the right direction and made the man page more efficient than googling, but many others haven't.

IMHO, the minimum expected from a man page is to be complete. For example, this link does not give enough information to understand why "tar cfz x.tgz x" works, but not "tar -tfz x.tgz"

It says in the man page explicitly that it's not complete and you should look at `info tar` for the full man page. Also, because the problem really has nothing to do with tar -- every man page doesn't need to explain how old/short/long options work.

Section 3.3.3 "Old Option Styles" covers exactly the situation you describe.

> This old way of writing 'tar' options can surprise even experienced users. For example, the two commands:

> tar cfz archive.tar.gz file

> tar -cfz archive.tar.gz file

> are quite different. The first example uses 'archive.tar.gz' as the value for option 'f' and recognizes the option 'z'. The second example, however, uses 'z' as the value for option 'f' -- probably not what was intended.

> Old options are kept for compatibility with old versions of 'tar'.

> This second example could be corrected in many ways, among which the following are equivalent:

> tar -czf archive.tar.gz file

> tar -cf archive.tar.gz -z file

> tar cf archive.tar.gz -z file

I've just never understood why tar can't have sane defaults like zip. Why do you need three or four cryptic arguments to do the most basic use case?

Its like find. I try to remember the stupid syntax and just give up and use locate instead.

> I've just never understood why tar can't have sane defaults like zip.

Because tar means "tape archiver", and back when it was created, most of the time, you only needed one option: c, t or x (create, test, extract). You didn't need to pass f (file) because you actually piped tar to something that would append to a tape device (or read from it). And back then, compression (z, j, J, a) wasn't common place for tapes.

The most complex I have is this one in a deployment script:

    ssh -n -C -x ${DELIVERY_USERNAME}@${DELIVERY_HOSTNAME} tar ch 
    -C ~${DELIVERY_USERNAME}/${VERSION_PATH}/Escape/AIR_Delivery/PWP_Delivery
    Configuration_Files Executables Libraries Scripts
    | tar x -C ${install_appli} --transform 's,^Executables,bin,;s,^Configuration_Files,config,;s,^Scripts,config,;s,^Libraries/PWP_Configuration_Application.jar,config/PWP_Configuration_Application.jar,;s,^Libraries,lib,'

You should make github gists of these.

Reply on news.ycombinator.com