Slashdot Mirror
Learning Unix for Mac OS X Panther
This book focuses on those of us in the Mac OS professional world who have become Unix system admins by default with the introduction of OS X, and could stand to have a handy UNIX reference nearby, particularly if the Finder freezes in Apple's latest version of their BSD/OpenStep blend of a UNIX operating system.
As the authors explain in the book, the best justification for understanding and using the UNIX components present is Mac OS X is the same as in any other UNIX-family operating system: power and control. The Finder (Mac OS X's graphical desktop manager) can't do everything, so this book provides information to help power users and technicians resolve issues, install software, or create an optimized experience, all through the Terminal.
Chapters 1 and 2 provide a very helpful tutorial on the Mac OS X Terminal application, from showing the benefits of customizing the Terminal, the concept of shells, UNIX command syntax, and other obscure but useful settings that strengthen the power of the application when accessing the BSD innards of Mac OS X. Arguably, these two chapters are the strongest guide on Mac OS X's Terminal application (as it relates to its UNIX roots) that I have seen in any Mac OS X book to date.
Chapters 3 and 4 handle understanding of the UNIX filesystem, administration and superuser access, privileges, handling external volumes, file and directory names and the like. Mac OS X, while a BSD at heart, doesn't map out everything in a traditional UNIX-style directory format--at least, not from the Finder's view. Through the Terminal, a user can see the underlying, otherwise-hidden UNIX directories. The authors go through some basic but very helpful situations such as changing file and owner permissions, which can be changed from the Finder with greater ease in Panther, but not with the same finesse as done from a command line.
The file management chapter moves readers through the classic commands for moving, editing, and copying files from the command line, which can be very helpful for administrators of Mac OS X systems who must attempt repairs by SSH, for instance, and don't have access to the usual graphical elements that generally make Mac OS usage so easy. The authors don't pick sides in the vi vs. pico debate, and just offer the basic instructions on how to use either for your editing.
The book continues with the same level of complexity that local system admins or power users require in issues such as printing via CUPS, handling processes that the Finder doesn't show, using the X11 application, using Fink (a Debian-style installation application) installing OpenOffice and GIMP, using FTP and secure shell, using Pine and Lynx, and more.
For a book of just 168 pages, the authors pack quite a bit on making a Mac OS X system work from its Terminal roots. New Mac OS X system administrators will find this book most useful, particularly if their UNIX experience is lacking or radically different from what Mac OS X presents. Experienced *NIX users who bought a new Mac may find the book a good intermediary to demonstrate how Mac OS X Panther differs from the *NIX boxen they've used in the past.
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.
The Finder (Mac OS X's graphical desktop manager) can't do everything...
"Yes it can."
-Steve Jobs
If you don't know what a command does, type "man [command]" (without the quotes, of course).
Strange women lying in ponds distributing swords is no basis for a system of government.
I am a *nix admin and I have several friends that are OS X users that want to take advantage of the terminal/BSD side of the operating system. I am going to recommend this to all of them.
Evolution or ID?
man man
man cd
man pwd
man ls
man cp
man mv
man rm
man chmod
man more
man ps
man rm
man chmod
man more
man head
man tail
man grep
man passwd
Knock yourself out.
Anybody who knows enough about panther to enable the root account and login to a shell with that user, will know better than to enter that command line.
-dewhite
That's a new one to me. I must find some pico users to have flamewars with over that one...
I've gotten a shiny new iMac with OS X.3 on it, and I'm still learning the ropes. I'm slightly amazed at all the wierdnesses I can do with it, you can script almost anything with Applescript, and there's a million little details that do wierd shit, or behave as I'm not used to. So where is the Learning Mac OS X for the unix geek? The unix and mac world is so divided on the machine, yet works together seemlessly.
I haven't had my coffee yet, I'll ramble on about my experiences with Mac OS X elsewhere. But my question remains: what are good books/resources for the person who is already a unix geek?
Using the Mac OS X Terminal (HTML) or Using the Mac OS X Terminal (PDF)
Consensus is good, but informed dictatorship is better
I've seen a few of these introductory unix books for Mac admins, but what if you need something more? If you have trouble configuring Apache, the Apache website doesn't help much because OS X has files in different locations. I know how to use ls... does this or any other book get into a deeper level?
Recommended new moderation categories:
-1, Mac users have no sense of humor
-1, Joke at the expnense of someone other than M$ - note 1337 M155P3||1N6!
I recall being at an Apple seminar once where they had demo of a then preproduction version of MacOS X. The audience consisted of local Mac support techies as well as casual users. There were many glitches throughout the demo, and many explanations from the presenter as to why MacOS loaded so slowly etc etc. He used this time to explain to the audience that the MacOS kernel is based on Unix. I wasn't sure at the time how many people in the audience would grasp that concept, but it became painfully clear near the end of the presentation when he finished things off by opening up a terminal window. I looked around and saw nothing but stunned, confused looks on people's faces. The presenter followed by explaining how you could now use familiar unix applications like telnet and vi all within MacOS X. After then explaining to someones question regarding just what telnet and vi were, someone else followed with the question, "So...if someone on the Internet wanted to hack my computer, could they open up one of these 'terminals' and use 'telnet' to hack into my Mac?". Needless to say the presentation ended late that day, and I got the impression most of the audience left feeling rather uncertain about what just happened.
I think a Unix for MacOS publication would be useful for those migrating to Apple from some (any) other platform. For casual Mac users? No way is this going to be of any use to them. If they were so inclined, they'd already have some experience on another OS by now.
www.brownsauce.org
I use nano, and I flame the pico users!
Pfff. Real men cat > filename and do it right the first time.
Trolling is a art,
... Macolytes who have a use for the command-line can really use GeekTool to improve their quality of life. See this picture for an example of its GUI goodness.
Okay, okay, so it's sitting there just churning the CPU. But it looks cool enough to get me chicks, so I figured you guys could use it too.
I'm not normally an irrational zealous dickhead, but I figure "When in Rome..."
I think it's important that MAC OS X users learn to use the UNIX command line. Even if they don't like it, they need to respect it. If it wasn't for OS X being powered by UNIX, it would not be anywhere near as stable as it is right now. I'm not "dissing" OS X, because I use it and love it, but any user shouldn't be without the knowledge required to run the UNIX command line.
Essentially, anyone that uses MAC OS X (if they don't already) will see the power of BSD and UNIX and general.. and will maybe move their PCs (unless they have MAC only) from Windows to a variation of UNIX, such as BSD or Linux.
"Instant gratification takes too long." - Carrie Fisher
I'm an experienced *NIX admin who just got his first Mac (a Powerbook, and I'm hooked), and I'm struggling through what exactly *does* and *doesn't* translate from BSD to OS-X 10.3. I'd love to see a book that covers - to some degree - the differences. Anyone have a recommendation? Perhaps this book will be a close fit...
akad0nric0
This sentence no verb.
What is wrong with paying a few bucks to replace a brand new mouse that came with the system you just paid a couple of thousand dollars for?
It's only after years of experience with other operating systems, other computers, that I made the decision to switch to a Mac. Mac users I find can be very technical, just 'differently technical'. Technical doesn't mean "knows *nix". Maybe here, but not in the rest of the big wide world. . .
Curious about other writing I've done? There's some useful free info online at 404 error page, particularly for Apache admins, and another book that slashdotters will appreciate is my Wicked Cool Shell Scripts. And, yes, Virginia, the latter includes specific scripts for Mac OS X too.
It's a troll because it isn't backed up. If the poster had specified which tools didn't work, it would either be marked as informative or replies could correct it. Since their are BSD and GNU tools that are known to work in Darwin/OSX, one must provide proof of the contrary or accept a Troll moderation.
R: That voice. Where have I heard that voice before? B: In about 365 other episodes. But I don't know who it is either.
Well, the thing is, Apple didn't write most of the man pages. And you'll find some little oddities -- like daemons starting up from rc that are calling flags not mentioned in the Apple supplied man pages. [eg, syslogd -s]
The real problem comes from all of those commands that apple has so kindly added and didn't bother to create man pages for. Stuff like 'disktool' and 'scselect'. Disktool gives some usage info when you call it...scselect, well...
And how many others are there out there that people haven't yet documented? [those two were mentioned in MacOS X for Unix Geeks, but I've found others that I can't recall off the top of my head that were recommended to run on webpages for configuration changes, that I just can't find documentation for]
Build it, and they will come^Hplain.
Just so you know, the convention of /Applilcations and /Users is from NeXT, and makes logical sense when you think about it. All the unix tools are located in their standard directories (/usr/bin etc etc) but a good chunk of users aren't going to use them, they're going to use their GUI apps and such. Why would you want to put all your terminal apps in the same folder that your GUI apps are?
/usr/bin, if I added them to my Applications folder, I'd have 700 items in my folder. Now as a (hypotheticaly) non CLI familiar user, why would I want to have 700 items in my folder where I put my programs when I don't use most of them? I wouldn't. So maybe I might start deleteing them, or maybe I'll make folders to organize them, or move them. And then what? What happens when I install an app that calls those programs?
I have 644 items in
That's why there's a user level set of folders that aren't the standar UNIX convention.
T Money
World Domination with a plastic spoon since 1984
Here's a question. My SO has been using an original vintage iMac with OS9 for many years. She's totally non-technical. She's heard bad things from her old Mac friends about OSX (complexity, unfamiliarity, and so on) and so now when she's thinking of getting a new machine she's inclining towards XP.
My question is this, given that a non-technical person's experienced with both OS9 and XP, which is easier? To transition completely to XP, or to attempt to learn the new and different OSX? I don't think she's ever willingly opened a command prompt in her life.
Da Blog
No, real man influence the entropy source of /dev/random, get the timing right and read what they want to write from said device file using dd.
A monkey is doing the real work for me.
Real men use <alt> + number pad.
"Verbing weirds language." -- Calvin
If you have trouble configuring Apache, the Apache website doesn't help much because OS X has files in different locations.
/etc/httpd, log files are in /var/log/httpd, DocumentRoot is /Library/WebServer/Documents, and ScriptAlias /cgi-bin is /Library/WebServer/CGI-Executables.
/etc/apache, log files are in /var/log/apache, DocumentRoot is /var/www/htdocs, and ScriptAlias /cgi-bin is /var/www/cgi-bin.
/etc/httpd/conf, log files are in /var/log/httpd (symlinked at /etc/httpd/logs), DocumentRoot is /var/www/htdocs, and ScriptAlias /cgi-bin is /var/www/cgi-bin.
/usr/local/apache/conf, log files are in /usr/local/apache/logs, DocumentRoot is /usr/local/apache/htdocs, and ScriptAlias /cgi-bin is /usr/local/apache/cgi-bin.
Apache's files are in different places on different flavors of UNIX or Linux distributions - and they're different still if the administrator compiled from source.
On Mac OS X 10.3, configuration files are in
On Slackware 8.1, configuration files are in
On RedHat 9, configuration files are in
By default on most systems, if you've compiled from source and haven't changed any paths, configuration files are in
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Try Running MacOSX, which is like a younger brother to the venerable Running Linux.
"First you gotta do the truffle shuffle."
You don't subscribe to the false logic that every individual within a sub-group thinks exactly alike, do you? 20 years ago there were people saying that you don't need a CLI, and there were people *using* a CLI on the Mac (MPW). Today there are still some that say you don't need a CLI, and still people using CLIs (Terminal). Over that time-period some people have left the Mac world and some new people have joined it. Everyone is entitled to his or her opinion, even if you disagree (and believe me, I often disagree with other Mac users)
Try to avoid prejudice.
Where does this perverse notion come from that GUI users are inhernetly incapable of using a command-line?
There's a deeper cultural thing going on here. On this site it's not uncommon to see programming-types bash (pardon the pun) users of more graphically-oriented tools (like Flash) with incredible zeal. It's as if there's some sort of Berlin Wall between creative and techinical people, and any attempt to bridge the two is doomed to failure or must be opposed.
This is nonsense.
This seperation of arts & humanities from the sciences is a relatively recent phenomonon. It's when people work with both sides of their brains that beautiful things really start to happen. Look at Leonardo Da Vinci if you want the best example. Look at the power of tools like Flash when you get people working on it to use its more powerful features like XML parsing with ActionScript, remoting, video etc. Look at musicians who can manipulate their creations electronically. Look at the animators who produce beautiful work on the big screen like Finding Nemo, Babylon 5 etc.
A lot of creative Mac people will benefit from having a deeper understanding of the way their command-line works, and if they're approaching it from a different angle than traditional Unix fans then so what? Isn't a fresh persective a good thing? Likewise I think that a lot of Unix fans could do well to visit more art galleries and explore their creative side a bit more. It may make better programmers out of them.
For the record, I work on both sides of the fence and do an equal amount of creative and technical work.
Drill baby drill - on Mars
You really ought to check out GNU Screen, which AFAIK comes with OS X by default. Screen allows you to run a number of shells or other interactive programs in a single terminal, sort of like having tabbed interface. However, Screen gives you all kinds of extra goodies with this--you can lock your session, detach it and reattach from anywhere, monitor "tabs" for silence or activity, split the terminal between one or more tabs, and so on. Better than "tabbed" terminals by far.
there's joe, which I often find is installed on systems that don't have nano/pico.
/etc/apt/sources.list on a new Debian install ...
;))
It's not *quite* as friendly as nano/pico, but has enough similarities (and the built in status bar / help-reminder you crave) that I tend to use it when editing things like
(Of course, every UNIX system seems to have vi installed, so I wish I could remember its commands better
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
Actually, the perceived slowness is just the result of the sloppy refresh rate of terminal.app, but a MUCH MUCH worse problem is the overall cpu usage for just printing some simple stuff. try the following: run mplayer to play back some divx movie, and use top -u -s5 to watch how terminal.app is eating up to 15% of cpu just to display the stupid progress/cpu-usage messages from mplayer!
now, does anyone have a more efficient terminal? maybe xterm is still the king...
still running a x86? dinosaurs do exist!