Hacker News Reader

> Can you tell me what all the flags of `tar -xvzf` Yes.

x: extract

v: verbose

z: zip (or unzip) archive

f: file name to follow.

> Do you think you would ever discover that combination on your own from reading the man pages?

Yes. Turns out, I wanted to tar up my nodejs directory, but omit the `node_modules` folder.

> Of course the command line makes many things easier.

Exactly. I'm not a high level computer scientist, but I imagine, being able to easily deal with files and data would help things out quite a bit. So there while it can be painful to learn bash, it's something that pays off heaps in the long run. My opinion.

`z' means to use gzip compression when extracting or creating a tarball. `J' means xz, `j' bzip2.

For example, to create an xz-compressed tar file:

tar cJvf archive.tar.xz some_directory/

Generally, you can omit those when uncompressing, at least with GNU tar.

OpenBSD's tar is less friendly - it doesn't seem to try to autodetect the compression format. Last time I checked, it didn't support xz either. One had to install the package and then do something such as tar cf - directory/ | xz > something.txz

where the - means that the tarball is written to standard output. /dev/stdout would work as well.

Honestly, I think build system complexity and breakage, and library/dependency/versioning hell is a much bigger problem than just learning how to use tar. The number of times I've had autoconf configure scripts whine about not being able to find some library when it is installed for whatever reason...

What man page are you reading? "man tar" is very informative. Also, try reading the full documentation at "info tar".

Yes, I learned a lot of commands (including tar) from the man & info pages. If you consider "man tar" to be confusing, good luck with some of the actual CS concepts that are far more confusing. Tool documentation is nothing compared to e.g. the complexity of paxos or the dry verbosity of RFC 2616.

> bash is a lesson in language design failure

Bourne Shell is one of the best languages I've ever used. Have you actually read "man bash"? Or are you cargo-culting shell like a lot of people do instead of actually learning the language?

Trying to learn modern computing without this background is like trying to learn physics without calculus. You may be able to skipping it in theory, but that will require skipping almost the entire history of the field.

I have written many arguably complicated shell scripts. It is almost always a painful experience that involves things that are hard to look up because of terse and confusing syntax. There are plenty of examples. Dealing with executing commands with nested quotes (double and single) with file names with spaces, doing anything with arrays, [] vs [[]], the rules of subshells, loop syntax when dealing with space delimiter vs line break delimiter, the lengthy list of -flag if[[]] conditions, comparing strings to variables... when I say "design failure" it's completely from personal experience and frustration from trying to do simple tasks in bash and hitting confusing syntax wall after wall. I hope you are saying

>"one of the best languages I've ever used"

in an argumentative sense and not sincerely! Bash is obviously not capable of many things and seems limiting to choose as a favorite (main go to?) language.

Shell is a 'glue' language, not a 'be' language. It's for gluing things together, not for being something in it's own right.

Though yes, it'd be a lot nicer if arrays in particular didn't suck so much in shell.

Actually, I learned most command line options from the man pages. Tar, in particular, has a pretty darn useful man page, and on SGI, came complete with example use cases. The first few times I needed to use tar, I glanced through those pages, assembled what I thought made sense and gave it a dry run. After a time or two, I had what I needed and proceeded to use it for years afterword.

When exploring new software and systems, the man page system or it's equivalent is the very first thing I learn how to do. Having this skill, along with a basic idea of how to work through the use cases safely is a great skill! Sometimes I'm away from things for a while, or I get stuck with one that is strange to me, or new. I don't always remember, or I need a quick refresher too.

A glance at the consistent "man" type documentation, or maybe even the quick help many utilities give when no arguments are supplied is often all I need. This is a basic, "so? what is the lay of the land?" type exercise on par with most orientation type tasks. Nobody particularly enjoys doing them, but when they do, the stuff they do enjoy goes much better.

Re: early learning

Maybe some basic literacy is early learning! Today, one can expect to see a few basic ways we do things. Command line, shells and scripting, gui, python and other interpreters, java script, web interface...

An overview of these with some quick strategy, words of wisdom, maybe even a walk through on some representative examples would put all of this to bed early and quickly. How else are they really going to cope with computing? It's not like they can expect to only use the good stuff, can they?

In a way, this argument seems to be putting the cart before the horse. I get it. People want to get right into the good stuff, but the reality of systems today isn't like that. Why not enable people early?

Edit: And it seems the author is doing that enabling. He's careful to explain that it's necessary, important, foundation work. And doing it gets one to the interesting and new work too.

Good on him.

> Can you tell me what all the flags of `tar -xvzf` do? Do you think you would ever discover that combination on your own from reading the man pages?

Is this some kind of sad joke? Of course. The tar man page is 8 pages long. You can read it in its entirety in ten minutes. I agree that it's far from ideal, since you ought to be able to figure out how to use a command immediately instead of after thirty minutes of rereading a man page over and over again, but "ever"? "Do you think you would ever discover that combination"? What is wrong with you?

>What is wrong with you?

Do you want the list or the summary?

man pages are horrible.

I think git ( all version control, really ) would be conceptually easier to grasp with a visual representation.

> man pages are horrible.

Linux and GNU man pages can be horrible, yes. For great examples of not horrible man pages, look at OpenBSD. Their documentation is second to none. You can take what you learn by playing around with OpenBSD and apply it to just about any other UNIX-like OS.

Git documentation is especially bad. The book "Pro Git" does a decent job of covering the need-to-knows in an approachable way.