[mcguire]

He also goes on to say,

"Throughout this entire ordeal where I'm uttering ridiculous epithets like 'git pipe fork pipe stdout pipe stderr apt-get revert rollback pipe pipe grep pipe to less make install redirect rm rm ls ls -l ls tar -zxvf rm rm rm ssh mv ssh curl wget pip,'"

In other words, "ridiculous epithets" seems to be equivalent to telling the machine to do something. Have you got a way to get git to control your source without actually invoking git?

Workflow tooling can indeed be incredibly useful, but the context isn't the only requirement for success. If something underpinning that tooling changes or breaks, someone is going to have to understand what happened.

The people who regard that understanding as "ridiculous" are the worst people to work with and to my mind are the primary reasons that this "profession" gets little respect.

[loup-vaillant]

> Have you got a way to get git to control your source without actually invoking git?

No, but git does involve ridiculous epithets. No quotes, because I'm dead serious. As an interface, Git command line is laughable, and doesn't deserve a passing grade. Yes, it's the only one we've got. Yes, many interfaces are even worse. Still, that's no excuse. We can do better. Hopefully someone will: http://tonsky.me/blog/reinventing-git-interface/

---

Let's take a simpler example:

  $ tar -xzf foo.tar.gz

So, you have to learn the name "tar". The option "-x" for extract, the option "z" for gzip, and the option "-f" for file (by the way, the "f" must come last, or it won't work). What the fuck is this retarded interface?

First, why do I have to tell tar to extract the thing, since it's obviously a compressed archive? Why do I have to tell tar that it's in gzip format? It can decompress it, surely it can check the compression format? And why, why, WHY do I have to tell it I'm processing a file? It KNOWS it's a freaking file!!!

Surely there must be an alternative, like… like…

  $ decompress foo.tar.gz

I personally don't know of such alternative, and don't use them, because I was retarded enough to learn the basic 'tar' incantations by heart. Now that I know them, I can't summon the courage to use a decent interface instead.

But you see my point. Even for a simple tool such as tar, the common use case involves a cryptic incantation that shouldn't be needed in the first place. I'm sure many other UNIX tools are like that, I just didn't think about critiquing their interfaces thoroughly. Yet.

The core principles of the command line are very good. The level of relatively easy automation it provide is nothing short of amazing. This technology for the 70's is arguably more capable than most graphical interfaces in current use. But it does have its fair share of incidental complexity and useless quirks. We can do better. Let's not forget that.

[profsnuggles]

Lets take your tar example. The -z and -x options are flags, they specify binary on/off options. You can specify all the flags separately on the command invocation like so:

  $ tar -x -z -f foo.tar.gz

However typing -flag -flag2 -flag3 is too many keystrokes so an a convenience you can combine all the flags in one call -xzf. The -f isn't a flag though it takes an argument which in this case is the filename foo.tar.gz. The argument is required and comes directly after the flag. Which is why the f has to come last because that argument has to come right after. Order doesn't matter for the x and z because they don't take arguments they are just flags. It makes sense if you add in another flag like -C which also takes an option you would end up with:

  $ tar -xzfC foo.tar.gz directory_to_change_to

Which argument goes to which flag? Maybe the first flag gets the first argument? Then your argument order changes if you type in the flags backwards.

I don't know about your z flag, GNU tar doesn't need it. The x flag is needed because tar can do things other than extract like list the contents of the archive with the -t flag, or create a new archive with -c.

Finally why is the f command required? My first assumption was that maybe because you need to specify the output file when you are creating an archive. I took a look in the manpage and the reason is a lot more interesting.

  Use archive file or device ARCHIVE.  If this option is not given, tar will
  first examine the environment variable `TAPE'. If it is set, its value will
  be used as the archive name. Otherwise, tar will assume the compiled-in
  default.

I knew that tar's name comes from the phrase tape archive but I hadn't put two and two together. Of course you need to specify if you are writing the archive to a file because tar was created to back up data to tape! If you think about it tar is actually doing the "right thing". Considering why it was written tar has a sane default, write the data to the tape drive.

Maybe you already understand all this and I'm reading too much into your simple example. It feels to me though that when people have issues with something like the unix command line its because they just wanted to get something done and memorized an incantation to do it. There isn't anything wrong with that of course but a tool like tar is SO much more powerful than just decompressing files. Once you start to dig into it though there is an internal consistency and logic to it though.

[loup-vaillant]

> Maybe you already understand all this

Yes I do. Every single item. I just feel for the hapless student that is required to send a compressed archive of his work to the teacher, and is using tar for the first time.

There's only one little exception: I didn't know GNU tar doesn't require the '-z' flag (which by the way means 'this is a gzip archive') when extracting tar.gz archive. Anyway, I bet my hat that the '-z' is required if you compress something and output the result to the standard output: there will be no '.gz' hint to help the tool magically understand you want it compressed. If you omit it, tar will likely not compress anything.

The '-f' option is the most aggravating. Nobody uses tapes any more. Tar was doing the right thing, but no longer. -f should be dropped, or rendered optional, or replaced by '-o' for consistency with compilers… As it is, it's just ugly.

> It feels to me though that when people have issues with something like the unix command line its because they just wanted to get something done and memorized an incantation to do it. There isn't anything wrong with that of course […]

Actually there is. The users want to do something (usually a very common case such as compressing or decompressing an archive), then they have to memorise an arcane incantation. Yes, tar can do much more. Yes, the command line is powerful and flexible and more. This is Good. (Seriously, I miss my command line whenever I have to touch Windows.) On the other hand, some common cases are just not well handled, and it is full of idiosyncrasies that have nothing to do with the aforementioned benefits.

When the user wants to decompress files, it should not be more complicated than 'decompress archive.tar.gz'. Though thanks to an uncle comment, I now know of the 'unp' tool, which works just like that: 'unp archive.tar.gz', and you're done. (And the man page is refreshingly short.)

[tedunangst]

You don't specify -f to tell it you're processing a file, you specify -f to tell it that the next argument is the filename. And it doesn't have to come last.

    tar -z -f foo.tar.gz -x

That's a perfectly valid tar command. Also, obviously you have to tell it that you're extracting the file. How else would it know that you don't want to create an archive?

[loup-vaillant]

You're the second commenter who believed I didn't know this stuff.

I know that, and more. But go and explain each and every flag to a student that just want to extract the first lesson of his first UNIX course. At this point, this is all magic and arbitrary.

[onli]

> $ uncompress foo.tar.gz

Try unp, it's in the repo.

[loup-vaillant]

Told you we could do better! Seriously you just made my day. I'll use this from now on.