
An Introduction to Unix (2014) - michaelsbradley
http://www.oliverelliott.org/article/computing/tut_unix/
======
zokier
I just began reading this, and I don't like it that much. The random attacks
against GUI seem unnecessary and distracting. But worse than that there seems
to be quite a few factual errors, like:

"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](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.

~~~
cssmoo
Great points about robustness.

For the first time ever I had to deal with xargs and find together last week.
Bear in mind I've been using Unix for about 20 years now. Telling one command
to null delimit stuff and another to parse the nulls is horrible. Especially
seeing as this only came about because one directory happened to have a lot of
files in it and the 11 year old script just went snap. I'm perhaps lucky I've
never encountered this.

The author needs to take a look at powershell. Surprisingly I wrote a job site
scraper in it in about 10 lines of code. Html parsing, data access etc are
right there at your finger tips. That and it'll quite happily move
23TiB/1780000 files in a single incantation without wincing once.

Colour me impressed (as an old Unix die hard)

~~~
tomsthumb
> For the first time ever I had to deal with xargs and find together last
> week. Bear in mind I've been using Unix for about 20 years now.

I'm really curious about this. Do you have a very specific workflow that gets
around that need or an alternative that would replace find + xargs? Is your
job pretty niche? It just seems like I _need_ it a few times a week minimum,
and I'm not really sure what would replace it off the top of my head.

I do agree on powershell being quite slick. Sometimes finding what I want is a
process, but so was unix in the beginning.

~~~
cssmoo
I just don't deal with lots of files really. I tend to deal with a small
number of very big ones instead and the paths have always been short. To
replace it, no idea.

------
mlangdon
For those stuck with windows for some reason, note that Cygwin[1] is a not too
painful way to get that *nix feeling. Note that things get a little weird if
you start, e.g., running python from Cygwin.

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

~~~
falcolas
If I may offer a dissenting opinion?

If you are on Windows, you would gain quite a bit more from learning
Powershell, not Unix. Powershell has taken many lessons from Unix, and (dare I
say) improved on many things. It's absolutely worth learning, if you are going
to work extensively on Windows.

~~~
a3n
This is probably true, if you're mostly only going to work in Windows.

But if you're going to work in *nix and Windows, your bash/cygwin
skills/experience will be useful in both locations, and much of your work will
be reusable between the two worlds.

Powershell is Windows-only, which is fine if your life is Windows-only or
Windows-heavy.

Not that there's anything wrong with knowing and using Powershell.

------
nisa
I personally prefer [https://nixsrv.com/llthw](https://nixsrv.com/llthw) \-
it's concise and the focus is on more on important details... I also enjoy the
attitude and explanations on this site. It forces you to learn to learn and
explore on your own - which is essential to learn Linux/Unix.

------
Numberwang
Can people who have the relevant knowledge give their input on how good of a
starting-point this is?

~~~
tambourine_man
Seems ok at a glance.

If you want a classic though, check out Unix Power Tools at O'Reilly

~~~
a3n
I have the hard copy and ebook, and it's great. I've been using some type of
∗nix OS since the late eighties, and I will never learn the whole thing. Unix
Power Tools is one of the few door-stop sized books that are worth having. A
few of the items are somewhat dated, but ∗nix today, at least what's covered
in UPT, is mostly what ∗nix has always been.

EDIT: changed ascii asterisk in front of all instances of nix to u+2217, the
plain asterisk translates to large bodies of italicized text on HN. Which I
knew.

------
vram22
Related: for people who want to write their own Unix commands [1], not just
use them :) -- an article I wrote for IBM developerWorks:

[http://jugad2.blogspot.in/2014/09/my-ibm-developerworks-
arti...](http://jugad2.blogspot.in/2014/09/my-ibm-developerworks-article.html)

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-...](http://jugad2.blogspot.in/2014/10/print-selected-text-pages-to-pdf-
with.html)

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

------
phren0logy
Taking a glance at this, it seems very unlikley to unseat my favorite intro
book:

[http://linuxcommand.org/tlcl.php](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.

~~~
vram22
Yes, that book is good. I had reviewed it for O'Reilly, a while ago, here:

[http://shop.oreilly.com/product/9781593273897.do](http://shop.oreilly.com/product/9781593273897.do)

2nd review from the top (currently), reviewer id is vasudevram.

------
morenoh149
Very related. I was about to write a js to shell script compiler when I came
across [https://github.com/BYVoid/Batsh](https://github.com/BYVoid/Batsh) it
takes C/java-style code and spits out a bash script. The shell script will run
on windows osx and *nix.

------
lpeters
It is obvious a lot of attention was put into creating this document. I
particularly enjoyed the sections on awk and sed. I have seen many others
attempt to explain these tools using many more words and circulate much more
ambiguity.

Bravo!

------
platz
[http://blog.sanctum.geek.nz/](http://blog.sanctum.geek.nz/) has some of the
clearest yet most nuanced Unix tutorials I've ever seen

------
vram22
Error here:

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

Unix is not a language, but an OS.

------
danso
It's funny to come across this just now...for the past quarter, I've been
teaching a basic programming class that focuses on the command-line...the most
complicated thing we cover is sed (here's a list of tools we use:
[http://www.compciv.org/unix-tools/](http://www.compciv.org/unix-tools/)) and
the homework I've assigned generally involves scraping and data-munging, such
as writing a batch job to scrape the USAJobs.gov API
([http://www.compciv.org/curriculum/](http://www.compciv.org/curriculum/))...

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.

------
hf
The author tells me to 'Please enable Javascript!'

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?

~~~
asdfrob
just remove div#container visibility:hidden and it works. Why does it require
JS when there's no need for it at all?

------
majika
For some reason, the author disallows people from viewing pages on his site
without running scripts from his domain and from jquery.com.

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.

~~~
icantthinkofone
The modern web is scriptable and the days of "no javascript" are over. If you
turn off javascript, you are one of less than 2% of the web that does so but
you know what you did and the consequences so you also know how to fix the
problem.

~~~
inclemnet
> The modern web is scriptable and the days of "no javascript" are over.

But why should we accept this? Why does it justify pages like this one, that
_don 't_ need javascript but deliberately fail if you don't enable it?

~~~
icantthinkofone
Because the marketing guys want it and to write for fallbacks takes time.
While this instance is not about marketing, my point is that turning
javascript off makes you one of the few and I would have to determine if that
2% is worth the effort.

Some companies won't target your browser if you have less than 5% market
share. Even 10% market share. So imagine when I find out you are less than 2%
market share (no js users).

For my web dev company, we have about 10 clients. None of the visitors have
ever had javascript turned off that I'm aware of over the last several years.

