An Introduction to Unix (2014)

"Under the hood Windows, unlike Mac OS, is DOS- rather than unix-based"

Last DOS based Windows was released like 15 years ago. At that time Macs had their own weird OS too.

"A general point about unix commands: they're often robust."

Unix commands, robust? You gotta be kidding me, they are great for quick ad-hoc hacks, but robust they are not. Just as an example here is how the common task of handling can fail: http://www.dwheeler.com/essays/filenames-in-shell.html

"For example, with ls you can use an arbitrary number of arguments and it obeys the regular expression (more about these later) convention that an asterisk matches anything"

How this is an example of robustness? Besides globbing is not regular expressions. In regexp you'd use .* to match anything, not a bare *

> However, a file in Microsoft Word's proprietary and unknown formatting is utterly unusable.

While I'm no fan of Word, it is very much arguable that Word file format not anymore proprietary or unknown.

> I used to use Smultron until I found, unforgivably, that the spacing of documents when you looked at them in the editor and on the terminal was different.

Let me guess, tab width difference? Yeah, that is how tabs work and not really a fault in the editor.

[1] http://www.cygwin.com

http://jugad2.blogspot.in/2014/09/my-ibm-developerworks-arti...

And this post shows a practical use of that utility:

Print selected text pages to PDF with Python, selpg and xtopdf on Linux:

http://jugad2.blogspot.in/2014/10/print-selected-text-pages-...

[1] In C, but the guidelines shown are also applicable to writing Unix commands in other languages like Python and Ruby.

http://linuxcommand.org/tlcl.php

I consistently recommend The Linux Command Line by William Schotts. It's available in print through New Starch, or on the web. It's very clearly written, and practical.

Bravo!

>(2) it's the most natural port of entry into all other programming languages;

Unix is not a language, but an OS.

I agree with the OP that conceptually, the command-line is the best place to start learning programming...the idea that a tool should be kept simple, but that it should be easy to connect things together, and that it's up to the human operator, not the computer, to do this work...this is very powerful, and something I wish I had learned early on as a programmer. The way that Unix tries to think of everything as text is also a powerful concept, because for most beginners, they think of file formats as being "magical" and immutable, they don't have the concept that at the core of it, everything is just binary (everything being "just text" is a nice middelground from OS magic and trying to read binary)

However, the beauty of this philosophy is hard for non-programmers to appreciate or take advantage of. Moreover, things that I love as a programmer, such as silence-by-default and sparse error messages...are massive stumbling blocks for beginners. While I've done enough programming to appreciate silence, it's another thing to be a beginner who has never edited code in a text-editor to deal with "silence"...perhaps the biggest obstacle is the high difficulty in debugging. I can generally pinpoint any error in seconds...but this is only after years of general programming. The way that Bash continues on when an undeclared variable is referenced (via a typo) has led to hours of frustration for my students.

I think next year when I teach the class, if I do Unix again, I'm going to commit the first two weeks to muscle memory and flashcard-like memorization...it's too difficult to get the higher-level concepts of programming while you're stumbling around with recognizing variables. On the other hand, I think I may not try to teach Unix again, and will just stick to Python. One of my goals of teaching Unix was to avoid complexity and especially, things like OOP...I think Python can be carefully taught to fit that route...though I'll miss the ability in Bash to do such real-world tasks as curl, parse, and analyze a webpage in just two lines.

Edit: There was also a practical reason for doing things in Unix...all my students have different kind of laptops and OSes...and Stanford's shared computing runs on Ubuntu. So they did all their assignments on the shared computing cluster. That led to another issue of not being able to easily edit script files, in the way that you can do with Sublime Text on your own OS.

I counter: 'Please enable HTML!'

In all seriousness, it's text, images, links. There are no user accounts, no dynamically updated database of 'favourited' sections, no per-paragraph instant chat, the page is remarkably atrocity-free!

Hence, this page seems very much un-Unix-y: Solve problems at the lowest level of complexity, what?

You can get around this by opening up your web inspector, and disabling the `hidden: true` rule on the top `container` element.

Nothing on the page (or in related linked pages on his site) seems to require JavaScript.