Learning Unix for Mac OS X Panther

sympleko (Matthew Leingang) writes "In Neal Stephenson's manifesto In the Beginning was the Command Line , he writes about his favorite command-line utility: wc. As simple as can be, wc counts characters, words, and lines in a file. 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? BBEdit is a little easier, if you know the button to click." Read on for Leingang's review of Learning Unix for Mac OS X Panther, which seeks to reconcile the conception of user friendliness in OS X's Aqua with the sometimes-denigrated command line.

Learning Unix for Mac OS X Panther
author	Dave Taylor and Brian Jepson
pages	168
publisher	O'Reilly
rating	8/10
reviewer	Matthew Leingang
ISBN	0596006179
summary	Nice and Easy

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.

Word Count in Word

[AKAImBatman]

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.

Command line in OSX

[trisweb]

Just the other day I was fixing a friend's mac, and while I hadn't used OSX all that much, I do use linux, so I asked him, "okay, open up a terminal" because I knew it was possible, and it was so nice to be able to use (just about) everything I could in linux. It's definately something I wish Windows had...

You're being disingenuous

[Dink Paisy]

In Microsoft Word, I go to the "Tools" menu and choose "Word Count..."

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.

Re:Word Count in Word

[MrBlackBand]

With a command line, you speak directly to the program, if you know the language to use.

But what if you don't know the language to use? That's the main advantage of a GUI over a CLI. If you don't know how to do a word count in a command line environment then you must resort to looking it up in help. If you don't know how to do a word count in a GUI then all you have to do is explore the menus to find the command. Every command is already there right in front of you.

Typical OS bigotry

[Anonymous Coward]

Do I know how to count characters in a word document? Certainly. And, best of all, it will actually count characters, in any character set, not just in ASCII or other similar 7/8 bit sets.

But that's not really the point. Knowing how to do something in one OS does not make the one you are ignorant about an inferior OS. If you truly do know both OSes, then I'll listen to your opinions. Until then, I'd stay away from making comparisons.

It is the height of arrogance to assume that if you don't know something that it must not exist.

how many ways to do wc in a gui (word)

[yagu]

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):

• at least two versions/ways to do wc in a word doc within the first 10 posts, and....
• a real attitude from the anointed who had the "answer".

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.

adding to my previous response

[Dink Paisy]

The author of the review (and apparently the author of the book as well) are proponents of the view that each tool should be as simple as possible and do one job well. That just doesn't make sense any more. Now we have large, monolithic command line tools that can do many jobs well.

Having one large, all-purpose tool is better because instead of having to learn many simple tools with different syntax and stringing them all together in a massive chain of fork()'s and file handles, we can use a single tool that is more sophisticated, more consistent, and more resource efficient for big tasks. As Rob Pike said in his interview here [slashdot.org] so recently, the days of one tool doing one job well "are dead and gone and the eulogy was delivered by Perl."

Re:Word Count in Word

[Jeff DeMaagd]

It's faster. find ~/ -type f | wc -l is easier finding my mouse, plugging it in, waiting for usb to init, then navigating around.

Wow. I think you'd make a great benchmark designer. Pick an obscure task that almost nobody needs done, stack the "other" side with an unusual configuration for modern computers and use it as a case in declare that "your" way is a lot better in general.

Speed of command lin

[SeanDuggan]

Actually, given how slow Windows Explorer tends to be parsing directories, yes it may be much faster. I still remember a friend of mine deleting a large directory of temporary items. After 10 minutes of waiting for windows to finish displaying the whole directory, he dropped down to MS-DOS and deleted them all with one command and about 5 seconds of runtime.

There are definitely speed advantages to command lines.

Re:Word Count in Word

[ViolentGreen]

The command line is an obfuscation and a hinderence to people who really know what they want to do.

I'd like to modify that to say "The command line is an obfuscation and a hinderence to people who only know what they want to do and not how to do it."

The command line is extremly powerful. The GUI has it's place though. If you put someone in front of a command line with no insturction, they will have trouble getting around. There are 100+ keys on a keyboard as opposed to 2(3) buttons on a mouse. If you do enought clicking on any desktop environment, you can figure out how to get at least somthing done.

A GUI can be superior to a command prompt in some situations as well. Say you want to move 15 dissimilarly named files in one directory to another. In a GUI, you open up two "explorer" windows, use your mouse to select exactly which files you want and drag them to the other window. With a CLI, you have to type the 15 distinct file names as well as the destination folder. You could end up with the final command being 3-4 lines long and are more likely to make errors.

A GUI can make things easy that are tedious in a CLI. A CLI can make things easy that are tedious in a GUI.

Thankfully you don't have to choose one or the other. There's no reason to.

Rant time

[edremy]

Word count. What a moronic example. Let's imagine I'm a typical Word user vs. a typical Unix user

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.

Re:Word Count in Word

[bsartist]

"Unix guys" really don't even use a gui

Nonsense! A GUI is a *great* way to organize a few dozen xterms. :-)

Ignorance of the competition doesn't help

[Angst Badger]

I've been gleefully using the word counts in MS Word since the early 90's. There are actually two places you can get at them, and they're both readily accessible.

Speaking of the early 90's, this reminds me of a conversation I had on a TeX mailing list around 1994. I was thrilled with the idea behind TeX and struggling with the implementation. In the course of getting some answers about the surprisingly difficult process of setting up columns of varying widths, I overheard a conversation in which some TeX zealot was meandering on about all the things Word couldn't do. The problem was that all of the things he was talking about were things Word could do. He simply never got familiar enough with the application to actually use it well.

Word has its problems, it is true. It has a number of bugs that may or may not be a problem, depending on which features you use. Recent versions have become lumbering resource hogs without adding much new functionality. It lacks some expert layout features that would enable it to fully close the gap with real document layout software, though it's good enough 90% of the time. It's owned by Microsoft. It is, however, probably the most comprehensive and full-featured word processor out there. OpenOffice.org is getting very close, owing more to stagnant development at Microsoft than anything else, and may overtake it soon. I've started using it for complex documents and, most of the time, I don't miss Word.

You see the reverse with GIMP advocates. The claim that GIMP is as good as Photoshop can only be made by people who don't know Photoshop very well and whose graphic output is mostly limited to web pages. GIMP isn't even close to Photoshop, and as opposed to the situation with Word and Microsoft, Adobe lavishes so much developer resources on Photoshop that the gap is actually growing.

To return to the original topic, yes, wc is a handy utility. But it is really much more useful for data manipulation by programmers and other IT professionals than for anything else. And if you want to enlighten people about the virtues of commandline tools -- and they are indeed legion -- it helps if you don't immediately discredit yourself by discussing applications that you understand only very superficially.

Re:OSX

[Anonymous Coward]

Uhh, it's about as much Unix as *BSD and Linux, i.e. pretty much Unix in functionality, although not in certification.

Admittedly, it had some fairly non-POSIX features a couple of versions back, but it's getting closer. Then again, other "Unixes" (especially Linux) are non-POSIX as well.

wc counts words???

[sootman]

I always use it to find how many files are in a directory (ls -R | wc -l) or how many Windows boxes are trying to root me (cat /var/log/httpd/access_log | grep cmd.exe | wc -l) or how many visitors I got from a Slashdot story (cat access_log| grep slashdot | wc -l) or how many files I've touched this year (ls -lR | grep 2004| wc -l) or...

What I'm saying is, people who complain about the "how many ways do you know to count words?" example are missing the forest for the trees. 'wc' is one of countless small UNIX utilities that I sting together in new combinations ever every day. I don't write books or magazines, so I *never* care how long my files are in that sense. But seeing how many lines in a log file contain a certain string is useful every day.

Besides, "In the Beginning..." was written back in 1998 or 1999.

Beyond WC: The coolest things about unix in OS X is the interaction with the GUI. I can type "scp " and then drag a file from the desktop into the Terminal window and then finish with the destination server and path. I can be anywhere in the filesystem and say "open ." and a Finder window of the current directory will open. I can access the clipboard with "pbcopy" and "pbpaste" (though I must occasionally make a temp file and use 'tr' to change from Mac line breaks to unix line breaks). The final hurdle--dealing with two-part Mac files at the command line--will be solved in 10.4.

Re:OSX

[nine-times]

So what? Linux and BSD aren't Unix either, but people sometimes refer to them as "Unix" or "Unix flavors" or something along those lines, because, in many ways, they works similarly to Unix. If you know your way around a Unix box, with a few adjustments, you'll be able to figure out these other systems. And OSX isn't BSD, but a fair amount of it is based on BSD.

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.

funny they should mention find...

[Jamie Zawinski]

...since the first thing one learns about OSX is that it makes traditional "find" incantations completely malfunction due to filenames with spaces in them: you have to re-train your finger memory from

find . -type f | xargs foo
to
find . -type f -print0 | xargs -0 foo

For a good laugh, try explaining why that is necessary to a Unix newbie!

Re:Good points

[Smurf]

That is true, however Fink does do one thing by default that I find deplorable: it puts /sw/bin at the FRONT of your path instead of at the end, thus replacing (not physically, but effectively) basic system binaries like cp, rm, ls, df. No third-party library should put EVER itself in front of /bin unless the user specifically asks for it.

Wait a minute: first, Fink doesn't have replacement packages for cp, rm , ls, nor df. None of them get replaced even "effectively".

Now, suppose that they post an improved version of, say, ls. If you choose to install their version, then of course you want it to "effectively" replace the system's version. I mean, you should know what you are installing and why (unless you are rather clueless, in which case you probably don't want to mess with Fink/OpenDarwin/etc).

Allegedly, it would be better if they appended /sw/bin at the end of the path and added some mechanism to allow you to have a subset of binaries before the system ones, so that they can be replaced. And allow the user to decide in which group to put each package. As you can see, this can easily turn into a mess, so I'm glad they implemented it as they did.