Slashdot Mirror
Learning Unix for Mac OS X Panther
You can do a tremendous amount of stuff in Mac OS X Panther without ever touching the command line. This includes editing files, transferring them to remote locations, running a web server, and writing programs. Legend has it that some Apple developers wanted to ship OS X without a command-line application because it's anathema to the Mac "experience." But as Unix geeks will tell you, there are tasks which are much better suited to the command line. Routine, repeated, and automated tasks are some, as well as quick-and-easy access to files and directories.
This book is for the skilled Mac user who would like to know a little more about the operating system behind the scenes. There's also information about the Mac's brand of Unix, so someone familiar with Unix but new to the Mac will also find stuff to learn. For those confident in their Mac and Unix skills, however, there's not much new in the book's 168 pages. That's not to say it's a bad book; I found it quite enjoyable to read, and it's a good title to keep in mind to recommend to a Unix novice.
The book begins with an introduction to Terminal.app, the Mac's Unix terminal program. From the very basic (how to find with the Finder) to the fun (how to change the text and background colors) to the useful (how to save terminal sessions into double-clickable .term files), there's much that Terminal has to offer. There's even the cryptic echo '^[]2;My-Window-Title^G' command to change the title of Terminal's window.
The authors then introduce a few simple commands like date and who, and show how to manipulate the terminal's prompt. There's also alias which creates command shortcuts. For instance, if you always run ls with the -F flag, a command alias ls "ls -F" will save you some typing.
Each chapter has two sections which stand out. The "Practice" section gives a list of exercises to try, and the "Problem Checklist" is there to diagnose and fix unexpected behavior.
It's important (especially for those used to other OSes) to understand that in Unix, everything is a file, and all files are organized in the filesystem. This includes plain files, which might be Word documents or system logs; directories, which break up the filesystem into a tree; links, which allow file reuse with different names; devices, drives, etc. All these building blocks of the operating system are discussed. There are also a few pages on vi (which I found quite useful as my vi knowledge up to that point consisted of :q!.) and pico.
Printing on Mac OS X is much like printing on any Unix operating system; you can use pr to format text for line printing, enscript to format for PostScript printing, and lpr to actually queue a printer job. The addition that the Mac provides is a CLI to AppleTalk printers. You can use at_cho_prn to choose an AppleTalk printer and atprint to print to one.
One of Unix's biggest features is its ability to put together small programs to do many different tasks. To count how many files under your home directory are named foo, you can do find ~ -type f -name "foo" | wc -l. By breaking down a problem into components, you only need one-counting program, one file-finding program, etc. The book has a good chapter on this input/output redirection, and how to use those magic top-row characters |, >, >>, and <. Grep (and some light regular expressions) and sort are mentioned as tools for examining text. I thought sed would make a nice addition to this chapter, but perhaps it would lengthen the book too much.
Another advantage of Unix is its true multitasking. What may surprise newcomers to the command-line is that it is possible to run many jobs at once with a single interface. By running commands in the background, one can start large jobs and do other tasks while waiting. In the chapter on multitasking, the & modifier is covered, along with fg, bg, and kill to manipulate processes, and ps and top to report on them.
The command-line interface is lightweight enough that it can easily be extended by a network. This means it's easy (in fact, commonplace) to control a computer different from the one in front of which you're sitting. The authors cover the remote-shell commands ssh and its non-secure cousins, as well as other tools for accessing the internet such as ftp and curl.
The book closes with an introduction to the wealth of open-source software available for Macintosh, now that Macs run a functional Unix. The graphical Unix applications require an X server, which is easy to download and install. The authors show how to install Fink, the Macintosh open-source package manager, and a few big applications like OpenOffice.org and The Gimp.
The last chapter is both a resource list and suggestions for further directions. Those who learn a lot from this book may be interested in picking up shell programming or a scripting language such as Perl.
As I said at the beginning, the book is basic and well-written. Even if you feel it's beneath you, keep the title in mind when a newbie asks what the command-line is all about.
Matthew Leingang is a Preceptor in Mathematics at Harvard University. A funny sentence in the third person escapes him at the moment. You can purchase Learning Unix for Mac OS X Panther from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Think: do you know how to count the words in a Word file?
Tools -> Word Count
Why is that so hard? It's File -> Properties -> Statistics in OpenOffice.
Javascript + Nintendo DSi = DSiCade
Did you know that the number of words in a document is not a single value, but depends on the use of the document? I'm sure that Stephenson does know that: if you're writing for some audiences, you don't count the words in foot- or endnotes, whereas for others, you do. If you're writing for some audiences, you don't count "short words", whereas for others, you do.
And, of course, if you're writing in Japanese, wc counts your entire document as being one word long.
What does this have to do with Unix? It's a classic example of Einstein's dictum that everything should be made as simple as possible, but no simpler. The Unix command wc is a classic exmple.
For my current document, it reads:
Statistics:
Pages 23
Words 10,234
Characters (no spaces) 52,996
Characters (with spaces) 63,140
Paragraphs 107
Lines 660
One of the really nice things about GUI's is that they make rarely used commands (like word count) really easy to discover. You just look in the menu, and there it is. Compare that to a UNIX command prompt, where if you don't know how to write scripts and you don't know that the "wc" command is for word counts, you are lost.
Whoever corrects a mocker invites insult;
whoever rebukes a wicked man incurs abuse.
--Proverbs 9:7
grep -v -c "Something I know is not in the file" file.txt
- Carpe diem, quam minimum credula postero.
There's no GUI analogue, perhaps because anybody tempted to make one would add too many "features" that cluttered its ease of use. Think: do you know how to count the words in a Word file?
Tools -> Word Count
Yes, Word could be considered to be wc with too many other "features"!
Not to mention the Fink project, which adds tons of great apps to the command line.
Fink is nice, but it tends to make something of a mess. Even worse, that mess is mixed in with your current files, making it difficult to clean up later. I've found that http://packages.opendarwin.org works better. Don't access it through your web browser. just select finder, then click on the "Go" menu, then "Connect to Server...". Place that URL in the textfield and click "OK". You should now have a WebDAV archive of opensource binaries mounted on your desktop.
Have fun!
Javascript + Nintendo DSi = DSiCade
A robust programmable command line is a great tool, but for completely different reasons than listed.
It's powerful because you can create intelligent scripts to automate tasks. Then you launch those scripts by clicking them.
You aren't going to win anyone over by typing in some esoteric "find ~ blah | fart pipe * & (! exemo!'" command, when you could have just opened the search box and typed "foo". You're just going to look like an elitest dick.
Once upon a time, I knew all those stupid commands and switches and would pipe output through 98 different little apps to find something out.
Now I'm happy as a clam to spend my time and energy doing other things with my computer.
This summary, at least, is all about "using a command line to make simple tasks harder so that you can feel like a real 1337 h4z0r everytime you do something so mundane as count the words in a file"
I don't need no instructions to know how to rock!!!!
Already I'm seeing in the posts exactly what and why CLI users throw up their hands trying to deal with GUI.... and "wc" is a pretty good example. When the OP asked Think: do you know how to count the words in a Word file?, I knew without even reading on in the posts I was going to encounter (and, I did):
For those who didn't bother to sign up for the clue, the question was mostly rhetorical, and was an example of the diff between CLI and GUI. I know my immediate response wasn't, "I know EXACTLY how to do that in word," but rather, "Hmmmmm, I know I've solved that and found that "option" SOMEWHERE in word before, but I don't remember exactly where..."
OTOH, were you to ask CLI users the same question.... they would all know exactly how to use wc, and interestingly enough, had you asked the same question to the CLI users over the past fifteen years you would have gotten the same answers. So, in addition to a simple answer, CLI is a consistent one.
P.S.And don't even get me started about the menus with chevrons! Assuming for the sake of argument we are talking about the current version of WORD, have YOU ever tried to walk someone through this kind of stuff over the phone? With MS' genius implementation of self-modifying menus, you could "claim" something is in a menu when trying to help someone when in fact because of their use menus, their menu is completely different from yours.
Word: I don't know how to word count. I can either trawl the menus (Hmm, "Tools" looks possible- gee, option 4 is Word Count- maybe that works) or click Help and type word count and get the #1 option: How to count words. Farking trivial for poo-flinging chimp, perhaps less so for a typical user but having worked help desk, I've never gotten a call about this. I get a nice list of pages, words, characters, paragraphs, etc.
Unix. Well, gurus know wc. If not, how do I find out about it? Perhaps I actually know the "man -k" command. Let's try "man -k word count"- hmm, ~8 pages scroll by. I'm a really smart unix user: "man -k word count |more". Let's look at the entries
#1- BN_add_word (3ssl) - arithmetic functions on BIGNUMS with integers. Hmm- fuck no. (Omitting much BN badness)
#8- EVP_BytesToKey (3ssl) - password based encryption routine. What the hell? I just want to count words, damnit.
4 screens later, I actually find wc- maybe that will work.
"wc myfile.txt". (And it had better be ASCII text- don't try feeding wc a file in Japanese. Or an HTML file for that matter: Word correctly counts the actual text without the tags, wc won't) "1624 2282 53168 myfile.txt" Ok, which number do I care about? "man wc" Hmm- probably the second. But hey- it's scriptable. That means it's better, right?
Witness the amazing power of the command line: I can dick around for five minutes trying to figure out what command to use and end up with one vastly inferior for almost all tasks compared to the GUI version.
I love command lines, I really do. (I have to- I admin a couple of Unix boxes) But people vastly underestimate how powerful GUI tools have gotten and how long it takes to learn the arcane syntax of a typical Unix shell.
"Seven Deadly Sins? I thought it was a to-do list!"
Taking all that into account, I'm not sure what your point is. Maybe you were just trolling, but someone must not have thought so, since you were modded insightful.