Learning Unix for Mac OS X Panther 337
| 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.
Mac vs Unix (Score:4, Interesting)
I find it uncomfortable for obvious reasons (new way of doing things). Yet, while I only do file movement, touches, etc via the command line in unix/linux, and I only do GUI file touches, movement, etc on Windows, I find myself using an unwieldy GUI (Finder) to do the same thing on Mac. I can fire up an xterm and do it that way, but I don't 'want' to.
That is odd for me. Can't quite explain it. Mac is (even as a unix variant) its own creature. It leaves me feeling like I have the power of the universe in a little pretty living space.
Maybe cause I am new to it still.
Good points (Score:4, Interesting)
What I especially like about their use of the Terminal is pretty much anything that can be done in the OS, can be done on the command line. Example: changing a computer's name. Think fast: how does one do this in Windows? If you started saying "command line, net with options..." you know more than most. Windows coerces you to use the GUI. Mac encourages it, but doesn't force it (at least, since they got rid of OS 9).
Not to mention the Fink project, which adds tons of great apps to the command line. Again, I'm no Apple zealot, but their decision to have a robust command line in OS X was a great one.
Re:Word Count in Word (Score:2, Interesting)
I like to view it like this:
With a command line, you speak directly to the program, if you know the language to use.
A GUI is going through an intermediary translator who organizes words by categories you don't recognize, obfuscating an already complicated task by playing hide-and-go-seek with nested menus.
Get Mod 0 for MS Answer - Higher if OO or Combo (Score:2, Interesting)
Related titles (Score:3, Interesting)
As I am considering the advanced Unix users that browse this forum, I'd suggest having a look at that book too/instead.
Re:Command line in OSX (Score:4, Interesting)
I manage a dorm network with 44 computers, mine is the only one with cygwin installed, I guarantee it. So it's nice to go up to a Mac, open a terminal, and have it be useful.
More retarded assery from the zealot front (Score:4, Interesting)
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"
Re:wc gui analog (Score:3, Interesting)
To get things started, I whipped one up with 15 lines of applescript. For those too lazy to open up AppleScript Editor I posted a 'compiled' version. [beastiebox.com]
Just add extract and toss on your desktop or in your dock: drop files on to see the wc magic. Source code follows:I know you were half-joking, but when it's so easy, why not?PLEASE! It's all about the PIPE (Score:1, Interesting)
This is the great thing about command line unix; an astonishingly elegant solution if you ask me.
jj
Re:Word Count in Word (Score:4, Interesting)
I really wish Apple would bring this back... just because it is so damn cool an idea.
This [applefritter.com] page has more information, halfway down.
Re:Word Count in Word (Score:2, Interesting)
Amen.
I remember when my then about a year-old kid would point at something and then point at where she wants me to move it to. "Cut and paste," I figured.
Now that she can speak, she doesn't use the various variations of the sign language she developed early in her life.
The same thing happens with software: for a novice user, point-and-click, cut-and-paste and drag-and-drop are of course the only way they can interact with an unknown product. However, as the user finds out more about the product, point-and-clicking becomes too tedious. For example, when using Word, one would first go to the Format menu or to the toolbar to make text italic. However, sooner or later, people tend to switch to Ctrl-I as it is faster.
Command line (and not any command line, but something as powerful as a Unix shell with the Unix tools) is Ctrl-I equivalent for tasks more complex than making text italic.
Another way to think of that would be standard Windows calculator. It lets you punch the buttons with the mouse, which is what most users do. Those who have to do it enough times, start using keyboard. Those who do it enough times with longer expressions, start using bc, or a python interpreter, or another calculator capable of accepting complex expressions.
This leads me to a related point: one needs to know the language accepted by the command line to be able to use it. When the language has only one word ("Ctrl-I"), most people can learn it by accident. When it involves parentheses and plus/minus signs (calculator), learning the language may require some primitive thinking in addition to an accident, and fewer people bother to do that. Even fewer people bother to pick up a book on shell and learn it to be productive in command line.
What is sad here is that every day at work I see people who use Unix (Solaris) as part of their jobs. Not knowing how to edit the command line, or how to work with the history, entering every new command is a torture to them. As soon as I explain them how to edit the command line in ksh or how to run and work with bash, they instantly become more productive. What prevents most of them from learning this by themselves, is beyond me. It is even more puzzling as one of my colleagues is a lady in her fifties, who had never touched Unix until a couple years ago. Yet, she picked up a couple books, and now is as comfortable with command line as I am...
Re:Mac vs Unix (Score:2, Interesting)
But who needs a GUI when you can drop into a bash session anyway!
Re:Article seems to miss the point (Score:1, Interesting)
Have you considered that if a single one of those directory names had contained a whitespace character (not so uncommon these days), you might have hosed more than just CVS directories?
I'm all for command line programs in general, but face it: the current set of utilities is sorely lacking in ways to deal with today's file naming practices of spaces, newlines and non-ASCII characters. These days, I consider properly-written GUIs to be far more trustworthy at file manipulation, and I'm very wary of GUI wrappers that simply pass off those operations to the command line. You never know when one unprotected shell variable can ruin your whole day (see "iTunes 2.0 installer").
Maybe there needs to be something just slightly richer than plain text as a data interchange format? Something akin to "find -print0" and "xargs -0", but those are about the only Unix utilities that actually work that way so they have very limited scope.
Re:Word Count in Word (Score:2, Interesting)
I think you were kidding, but... I was working with mixed DOS & UNIX boxes, from a PC desktop, when Win3.1 came out.
My first reaction was "Wow, a great way to run programs at half-speed!" After trying it out for a week, I loved it: I could run a DOS app, a couple terminal windows to the UNIX boxes, and keep a Carbon Copy (PC remote-control over 2400-baud dialup) session going to troubleshoot a client. Stuck with console apps to avoid X overhead (we were running UNIX on Intel PCs - we needed every bit of resource we could get!)
Re:how many ways to do wc in a gui (word) (Score:3, Interesting)
The unspoken prime directive of interface design is No Moving Targets. It makes the UI harder to learn, slower to use and more frustrating. This implementation of menus does a grave disservice to novice suers (sorry, too many SCO articles). The best way to learn what a program does is to explore the menus. Making that an unecessarily time consuming and frustrating task discourages novices from learning [1]. People learn an interface both visually and kinetically. Kinesthetic memory plays a big role in how we learn software [2], moving targets retards this process. And by making everyone's menus different you create a support nightmare.
The main role of a menu is to group common functions spatially without taking up much of the screen (this is one reason why Apple has stuck with a single menu bar for 20 years). The introduction of hierarchical menus was a controversial move in interface design, since it hid some of the commands. The Views menu in a word processor is a good example. They're a necessary evil since menus can't be too long either. But when Windows hides the rarely used functions they remove those functions from the user's ken altogether, defeating the purpose of menus.
The rarely used fucntions can be the most important. Adding an extra click to get at the more powerful functions hinders the intermediate users. There is always the option to customize the menus or keyboard shortcuts, but requiring the suer to do that to easily perform any but the most basic functions is a sign of poor design.
Their concept was probably a Marketing idea: make the menus learn how the user works and adapt themselves accordingly. It looks great on a presentation but you wouldn't want to use it.
[1] Yes, you can point to this and say that Windows causes stupid users.
[2] cf. both Tognazzini and Nielsen