Tar is one example of a command with dubious usage syntax. But how about cp?

    cp a.txt b/c/d

Will this create a new file "b/c/d/a.txt", or will it create a new file "b/c/d"? It's not clear, and depends on the circumstances (if a directory b/c/d exists). There's a flag to control the behavior, but nobody uses it often, so nobody remembers that flag. The best way to assert that "d" is a directory is by adding a trailing slash, but there's no similar way to assert that "d" should be a file. I suspect that there are many bash scripts that are essentially broken because of this problem.

Rsync has a similar problem.

For cp you can use -nv. I discovered it two days ago. It displays what will happen without doing it.

tar actually makes sense with a little mnemonic:

  tar xzf $file
  - xtract
  - ze (actually gzip but fake-accent "the" is more memorable)
  - file

The most confusing thing about it for me now (after I eventually decided to learn it and figured out what you mentioned) is the missing dash. Somehow it works both with and without, which makes no sense considering how *nix tools work. Why is it made to be like that?

> Why is it made to be like that?

The history of tar is quite long, but the short version is that it was first released as part of 7th edition Unix. It was a successor to tp[1] which was introduced in 4th edition Unix, which was a successor to tap[2] which was released in 1st edition Unix. In 1st edition Unix (as far as I could tell from looking through the man pages), no command had '-abc'-style flag support at all (so tap's semantics made sense). I imagine that quite a few users did something like 'alias tap=tp' and 'alias tp=tar' when upgrading, and so CLI backwards compatibility was required. As a result, everyone learned to use tar that way and it stuck.

[1]: http://man.cat-v.org/unix-6th/1/tp [2]: http://man.cat-v.org/unix-1st/1/tap

And the (funny?) thing is that now the whole world has to suffer, probably millions of developers, because at one point tar had an installed user base of about 500 people. Yay for backwards compatibility :)

Make is another famous victim of this:

> Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history.

> now the whole world has to suffer

Bad example, since tar still works with a dash:

  tar -ztvf foo.tar.gz

> Make is another famous victim of this:

Now that is a much better example.

The same history applies to ps [1] which was introduced in 3rd Edition Unix.

[1] http://man.cat-v.org/unix-6th/1/ps

Though from what I've seen, most people I talk to use the POSIX forms (such as 'ps -ef') and aren't aware that there is a BSD form (such as 'ps aux'). I've always used the BSD form, even though I came to Linux much much later, but I guess which form you use comes from where you learned basic *nix commands.

I guess the lack of '-' with tar is more apparent because POSIX didn't create a different syntax, and so most people omit the '-' for terseness -- while with ps it would require learning a different syntax.

> I've always used the BSD form, even though I came to Linux much much later, but I guess which form you use comes from where you learned basic *nix commands.

I too use the BSD form but came from the Linux world. Probably it is just a matter of taste (a common answer to everything!).

> I guess the lack of '-' with tar is more apparent because POSIX didn't create a different syntax, and so most people omit the '-' for terseness -- while with ps it would require learning a different syntax.

I argue the ps situation is worse than tar exactly because of that reason. There are three different classes of options in ps, often with slightly different meanings and sometimes with two different long-form options only distinguished by their cases...

And all of this because originally, the Imperial Roman had no punctuation.

Wow, thanks!

Because it comes from an era before POSIX, when tapes were prevalent and bytes were costly.

Sometimes I dream of a nirvana in which:

- all unix commands support both short and long options

- option letters/names are, at least to a much greater extent than currently, common across different commands

No need for the ‘z’ :)

Yeah, tar is actually pretty simple these days. (At least GNU tar, don't know about other tars.) In 99.9% of cases you only need to know the following:

  tar caf $archive $file...      to create
  tar xf $archive                to extract

"x" will automatically recognize the compression format, and "ca" will automatically infer the desired compression format from the extension in $archive, e.g.

  tar caf backup.tar.xz /home/user

makes an xz-compressed tarball.

I still prefer to pipe through a compression program on principle. tar has no good reason to messing around with compression, per the Unix single-function philosophy.

to people who grew up with archive programs, "making all of this into a single file" and "compressing all of this" is the same thing; requiring two commands is counterintuitive

tar has trained us so well: "... tar is actually pretty simple these days"

You need it if you're processing stdin (curl ...file.tgz | tar xz)

For some reason, I think it would be more funny if the fourth frame was an exact copy of the third (with no text). I think it would be a simpler and less obvious route to the same "punchline".

> tar -h

bomb disarmed