René Frej Nielsen <rfn@altavista.net> wrote:
> Tak for et svar jeg kunne bruge, i modsætning til andre her i tråden.
Ja det var dejligt at se.
M.h.t. bøger havde MWJ (Macintosh Weekly Journal,
www.macjournals.com)
for nyligt følgende artikel, som jeg tillader mig at gengive i dens
helhed (den er ikke tilgængelig online).
Pas på, den er lang!
The Tao of Unix:
=========================================================
MacCyclopedia: The Tao of Unix
------------------------------
**Wrapping Your Mind Around Mac OS X's Core**
Want to start a fight? Remind a long-time Macintosh user that Mac
OS X is based on UNIX. In fact, just say "Unix"; modern style
guidelines have long passed by our archaic insistence on spelling
it in all capital letters, especially since it's not an acronym
for anything, so we're dropping that requirement (and yes, that
sound you hear in the background is the staff cheering). Just the
act of implying informality and friendliness by using lowercase
letters is enough to set off some people: "Nothing about UNIX is
friendly! Stop pretending!" It's enough to turn an ordinary
mailing list into some semblance of the WWF (you know who you are,
and no, it's not all the other guy's fault).
Computer operating systems come from different backgrounds and
were designed to serve different purposes. For example, the
original Apple II Disk Operating System (DOS 3.3, in its most
popular release) was designed to provide simple, quick, flat-file
disk access from a command line and to programs written in BASIC
while using as little memory as possible. (We've noted before that
the Chris Espinosa-written DOS 3.3 manual advises that while DOS
"can" run in 16K of memory, it really "prefers" 32K or more -
those aren't gigabytes or megabytes, but _kilobytes_.) Microsoft
Windows was designed to provide a graphical interface on top of
MS-DOS while maintaining compatibility with DOS disks, programs,
and syntax. The original Macintosh OS provided a consistent
graphic interface on top of a user-friendly file system, and not
much more; it fit in about 40K of RAM on top of its 64K ROM
component.
Now that tens of thousands of brave souls are using Mac OS X,
they're finding that the underlying assumptions of the operating
system have, from their perspective, changed. That's not quite
true - Unix's design hasn't changed much in the past three
decades. It is, however, not the Mac OS and was not intended to
be. The transition to an operating system based on Unix is a war
on two fronts. In one battle, Apple Computer and its engineers are
reexamining some casual Unix assumptions in Mac OS X. Where Unix
has traditionally been unfriendly and unforgiving, the Apple folks
are reimplementing and rewriting it, adding Mac-inspired
functionality and keeping the command line at bay wherever
possible. It's work in progress, but Unix veterans see the
differences. Instead of requiring you to use the command line for
file manipulation, Mac OS X has a Finder, though not as polished
or full-featured as the Mac OS 9 Finder (it _does_ have "Undo,"
though, a feature that should get a lot more mention than it does;
try it sometime). It automatically mounts disks as you insert
them, avoiding what is normally a cryptic set of Unix commands.
Running a Web server is as easy as turning on "Web sharing" with a
radio button, where Linux users get to dicker with command lines
and configuration files for the Apache Web server instead.
Yet no matter how hard Apple works, some parts of Unix will always
peek through because Unix is based on fundamentally different
assumptions than the classic Mac OS. The second battle is ours -
to understand _why_ Unix is different than Mac OS. Why hasn't
three decades of Unix development created a friendlier operating
system? Where should you learn more? Can you embrace Unix without
becoming a command-line junkie? Is everything you know wrong? The
answers lie in realizing why Unix behaves as it does.
**Obtaining Documentation**
Unfortunately, we can't teach you Unix. It has about a 30-year
head start on any attempt we could make to explain it. We could
write a few pages every day explaining a Unix command or idea or
strategy, but even if we did that for years, we'd wind up spending
a lot of time on aspects of the system that you'll never use and
still leave a lot unmentioned. You need documentation.
Since Unix has been around for three decades, authors have had
time to crank out a few books about it. Unfortunately, most of
them are for people who will be using Unix _as_ Unix - sitting
down at terminals, printing to line-based printers in a network
lab, maybe running the X Window system, but definitely spending a
lot of time at the command line. The most convenient of these
books we've seen comes from the dean of Unix publishing, O'Reilly
& Associates, and is called Learning the UNIX Operating System,
Fourth Edition [47] (hey, those are their capital letters, not
ours; the official O'Reilly stylesheet [48] prefers the mixed-case
spelling). Weighing in at just 92 pages with index, the "single-
session" book is designed for people who have to sit down at a
terminal and get something done. It doesn't explain the ins and
outs of every command, but it covers the basic concepts in a
compact and quick read. If you have to telnet into your Mac OS X
system from somewhere, it would be a good reference - but it's not
a deeply philosophical work.
[47] <
http://www.oreilly.com/catalog/lunix4/>
[48] <
http://www.oreilly.com/oreilly/author/stylesheet.html>
The book you want is Think Unix [49], by Jon Lasser. "Unix is not
a piece of software so much as a set of concepts, a way of looking
at and solving problems. _Think_Unix_ teaches how to use Unix
effectively for everyday tasks by teaching the design model," says
the completely unbiased back cover. "_Think_Unix_ takes an
approach analogous to that of a grammar book. Rather than teaching
individual words or phrases like most books, _Think_Unix_ teaches
the set of logical structures." If you're limited to one book for
your Unix journey, this is the one.
[49]
<
http://www.amazon.com/exec/obidos/ASIN/078972376X/ref=ase_gcsfIncorpora
ted/>
One of the first things Lasser recommends is learning Unix's man
command. Short for "manual," man provides descriptions of most
commands in your Unix system whenever you want them. Since most
Unix packages come with their own manual pages, man is always one
of the most up-to-date and easiest ways to find information about
a command. Unfortunately, most man pages pretty much assume you
know your way around Unix, but that's to be expected:
_Inside_Macintosh_ isn't written for Macintosh novices, either.
While man pages are quick and thorough help, they don't teach Unix
concepts, nor do they provide an overview of the entire system so
you can easily look at lots of commands at once to find the one
you want. That's where _Think_Unix_ and another venerable O'Reilly
book, UNIX In a Nutshell [50], come in. The Nutshell book provides
easy-to-digest summaries of almost every Unix command found across
systems, as well as in-depth look at many of the Unix utilities
you are likely to never use because, owning a Macintosh, you have
better ways of accomplishing those tasks.
[50] <
http://www.oreilly.com/catalog/unixnut3/>
For example, the Nutshell book includes full descriptions of the
powerful nroff and troff commands that format text files for
printers. You're free to use those programs in Mac OS X, but it's
hard to imagine why you'd want to type dot-commands (like ".ce"
for centering) in a text file when you can open up TextEdit and
click an icon on a ruler. Sure, you get more control with nroff
and troff, but you get even more control by writing your own
PostScript code instead of using a printer driver, or by designing
your own fonts. Who needs that much control? Typically, not you.
Lasser's book is great, but it approaches the operating system
design issue from the perspective of a Unix champion - someone who
has the choice of multiple operating systems and prefers to spend
his time on the command line. Again, typically, that's not you -
you'll use the command line as a tool when necessary or
appropriate, but unless typing commands just happens to suit your
particular workstyle, you won't want to keep a terminal window
open all the time. To get started on this journey, we need to see
how Unix's decisions differ from those of the Mac OS and how that
affects the way the system operates.
**The Prime Directive**
When you grasp why an operating system behaves as it does, you're
well on your way to making it work for you instead of the other
way around. A Macintosh example illustrates the point. When you
know that Mac OS aliases primarily track their target files by a
unique file number that stays with the file as long as it exists
on its disk, no matter how you otherwise change the file, it's
easier to understand that aliases can follow renamed, moved,
type-changed, and resized files - the file number stays the same,
so the alias can still find the original. You understand better
that when you throw a file away and replace it with a new one in
the same place with the same name, the alias still points to the
original file in the Trash: until the file goes away, the alias
follows it, even into the Trash; the Mac OS only looks for a new
file to replace the old one when the old file is actually deleted.
You also understand why moving a file to a new volume typically
breaks aliases - the target has a different file number on the new
volume, breaking the Alias Manager's primary hint about how to
find it. With just a little knowledge, your ability to work with
aliases and predict their actions increases dramatically, at least
until Apple changes the rules (and don't get us started on that
this week). Looking at an even more fundamental level illuminates
Unix and Macintosh choices more clearly.
The designers of Unix made two primary, fundamental design
decisions that shaped and informed everything else about the
operating system. The Macintosh was envisioned as a purely
personal appliance - one user, one application, one task at a
time. Over the years, the Mac OS evolved to allow multiple
programs running at once, but only through limited means that
preserve backwards compatibility. In late revisions, Apple has
also addressed the fact that most Macintosh computers are shared
by several people, either in a family or a school, with features
like Multiple Users and Macintosh Manager - but as you've probably
seen, some programs have compatibility issues with multiple user
software because it restricts access to parts of the system.
Macintosh programs aren't used to that limitation.
Unix, by contrast, was created when computer hardware was very
expensive, so multiple users had to share it. That's the first of
the two major Unix design decisions: it is an inherently multiple-
user operating system. There is no such thing as a single-user
version of Unix unless something is seriously wrong. You can
create a system with only one valid user, or always run as the
"root" user with full privileges, or even boot into "single-user
mode," but that doesn't change Unix's multiple user design: adding
other users is always just a few commands away.
**The Big Consequences** -- This fundamental choice about Unix
capabilities is one of the two aspects that, no matter what, Apple
will never be able to fully mask. It affects every part of the
operating system. If you started today to design a multiple-user
operating system, you'd wind up with a design similar in many ways
to Unix, because the multiple-user decision forces so many other
decisions. For starters, an operating system that allows multiple
users at the same time - all logged into the same hardware at once -
has to run multiple programs at once. There's no way around it:
if the system ran only one program at a time, it couldn't share
the hardware among multiple people, as its single focus would go
to a single user.
That, in turn, requires security: users shouldn't be able to mess
with each others' files, so Unix has intrinsic support for file
security, keeping other people out of your folders unless you
grant them access. To prevent other people from running programs
that might be in public directories, Unix also allows restricting
whether files can be executed even for people who can see them.
This security information is all built into the Unix file system,
but other information that the system did not need is not: there
are no file types, at least in part because the developers didn't
believe the system should restrict what you do with a file other
than for security reasons. Unix evolved around this decision, as
we'll see later.
Uppercase and lowercase filenames are different: "Movies" and
"movies" aren't the same thing on Unix disks (though they are on
HFS Plus) because the early systems didn't need to waste bytes in
code masking out the case of characters on the off-chance that you
hit the shift key when you didn't mean to. After all, everyone
types in lowercase, don't they?
For both security and stability, other users shouldn't be able to
poke into programs that you're running, so the Mac OS tactic of
cooperative multitasking just wouldn't work. Unix programs have
preemptive multitasking to keep one user from monopolizing the
expensive hardware, and protected memory to keep other programs
from snooping inside the programs you're running. In fact, since
time on older computers was often billed by the hour, Unix
includes built-in CPU time tracking in case the system
administrator needs to bill users for how much time they actually
used.
**The Smaller Consequences** -- Notice how the one design decision -
multiple users sharing hardware simultaneously - has dictated so
much of what you know about Unix, from the security features to
protected memory and preemptive multitasking. Yet even more parts
of Unix come from this design decision and how the original
authors of Unix implemented their choices.
Thirty years ago, the first Unix implementations ran on hardware
that makes an Apple II look huge: 8K or 16K of RAM and maybe 200K
of online storage. Virtual memory was a necessity, because even a
64K address space would be huge compared to actual RAM. The
thought of loading a program like Microsoft Word would have been
laughable. Heck, the thought of a single program that occupied
more than 10MB of RAM would be ludicrous - ten _megabytes_, for
pete's sake! That's enough to serve thousands of users! Most
programs need to run in as small a footprint as possible, say a
few hundred bytes.
The strict memory requirements led Unix's designers to keep the
actual operating system as bare as possible. The shell that Mac OS
X uses by default, tcsh, only has a few dozen built-in commands;
the hundreds of other available commands are all stored as
individual programs on disk. On our Mac OS X 10.0.3 system with
May 2001 developer tools installed, the "/usr/bin/" directory
alone has nearly 450 extra programs, ranging from Perl debuggers
to time servers to version control systems; there are another
hundred-plus commands in "/usr/sbin/". Each of these programs
loads, does its work, and gets itself out of RAM for efficient
system usage.
Since all of Unix's capabilities aren't in RAM at any one time,
the designers realized that the OS has to be able to link programs
together in useful ways. Using the traditional computer science
commands of input and output (you know, where the "input" to an
"add" program may be "2,2" and the "output" would be "4"), Unix
uses _piping_ and _redirection_ to let any program get its input
from a variety of sources, including other programs, and to
shuffle its output in similar ways. For example, when we wanted to
count the files in the "/usr/bin/" directory for the previous
paragraph, we couldn't quickly come up with a "count files in this
directory" command. However, we knew we could list the directory
in a long format, one file or subdirectory per line, with the "ls
-l" command. We also knew we could count the lines in text with
"wc -l" (the "word count" command, told to count lines instead of
words). We then used Unix's piping feature, sending the output of
ls as input to wc with the command line "ls -l | wc -l". The
result, minus a header line, is the number of files in the
directory.
Of course, it's far easier to open the "/usr/bin/" window in the
Finder and see it report "448 items," but that's not the point.
The original Unix designers couldn't have imagined a program like
the Finder where counting files in a directory would just be one
minor subroutine in a multiple megabyte application. Instead of
building large self-contained programs that wouldn't fit in small
systems, Unix is designed to support small, single-purpose
programs that work with other Unix programs to build more complex
solutions. In _Think_Unix_, Jon Lasser likens it more to a
language. It's not enough to know the words (the commands), you
also have to know how to put them together (in chains of commands
that link together) to fully express your needs.
Some Unix implementations have leaned towards larger programs:
nroff and troff are no tiny feats, nor are the TeX typesetting
system and the X Window system. However, the bread-and-butter Unix
commands that hardcore users type on the command line every day
are still small, focused utilities that work well because they
link to other programs.
**Vocabulary Test** -- If this concept seems familiar, you may be
thinking of AppleScript. When Apple first started linking
Macintosh applications with Apple events and AppleScript, the
designers had remarkably similar intentions. Instead of building
monolithic applications that contain every feature under the sun,
the designers believed that developers would write smaller, more
focused programs that talked to each other for complex features.
Word processors wouldn't have to include built-in spelling
checkers, instead using something like Word Services Apple event
suite to let you pick your own favorite spelling checker that you
could use across multiple applications.
Unfortunately, the major third-party speller was Spellswell Plus
[51], and it's pretty bad, so the concept never caught on. It does
survive in other aspects: Now Up-to-Date & Contact [52], even in
the new version 4, is two separate programs: Now Up-to-Date for
scheduling, and Now Contact for contact management. When
introduced ten years ago, they were sold separately, but that
ended a few years ago; in fact, when Qualcomm owned the software,
they even started to merge the programs back together into "Now
Planner" to work more conventionally. We're glad it didn't happen;
the flexibility still appeals to us. Adobe has kept Photoshop and
ImageReady as separate applications, though bundled, so each
retains its focus while working together through Apple events.
[51] <
http://www.working.com/spwplus.html>
[52] <
http://www.poweronsoftware.com/products/nudc/>
AppleScript itself was supposed to be a minimalist language, with
support for just a few control structures and data types, relying
on applications for the heavy lifting. Scripting additions, though
allowed, were discouraged because they added "words" to the global
AppleScript language; most everything you find in a scripting
addition could be implemented in a small scriptable application
just as easily. Apple adheres to this philosophy, more or less, by
keeping add-ons like Network Setup Scripting and URL Access
Scripting as background-only scriptable applications.
It's a very Unix-like philosophy, and it works well, but it's not
very commercial. It's hard for developers to sell small, focused
applications because customers tend to think they're not getting a
good value. There are great Apple event-driven applications
available, but they don't get much attention. One of our favorites
is Cyclone [53], a small application that can re-encode text from
any encoding the system supports to any other. All we need to
manage Unicode, UTF-8, Macintosh, Windows, and even ISO-Latin-1
encoded text is Cyclone; we don't need every word processor or
text editor on the planet to build in and test text encoding
conversion routines. Similarly, Unix users don't need complex
search-and-replace options in every tool when they can pipe input
and output through the powerful grep utility. Remember the
concept: small focused programs that work together. It's the Unix
way, and it's not a bad idea. However, just like learning any
language (including AppleScript), it's not something you can sit
down at the keyboard and master in five minutes. It takes practice
to tap into the power.
[53] <
http://homepage.mac.com/tkukiel/cyclone.html>
**The Secondary Directive**
Part of specifying any operating system involves deciding what
hardware it requires. The vast majority of operating systems in
computer history have been tied to specific hardware - for
example, the first Mac OS required the 128K Macintosh hardware and
nothing else. The TiVo operating system requires a TiVo digital
recorder, the PlayStation 2 operating system requires a PS2 box,
and so on. Only a few operating systems are hardware-independent,
meaning that with minor changes they can be recompiled to run on a
wide variety of hardware. Recent versions of Windows and Mac OS
have less stringent hardware requirements in the past, but it's
the open-source operating systems that have the widest reach.
On the other hand, more specific operating systems can be more
particular about the capabilities they choose to support. The
Macintosh, in particular, has always enforced three requirements,
two of which are somewhat unique for operating systems:
* A keyboard
* A mouse or other pointing device
* A bitmapped graphic display with square pixels and resolution of
at least 72 DPI (in fact, the Mac OS more or less assumes the
resolution _is_ 72 DPI, a requirement Apple's engineers and
developers would later regret)
Unlike almost every computer before it, the Macintosh has no
built-in text display. The Apple II, Commodore 64, IBM PC, and all
other personal computers we can easily remember have intrinsic
hardware and software support to display letters on the screen by
their ASCII values (or, in some really old cases, by other text
encodings). On the Apple II, storing the ASCII value of a
character in a certain memory location and turning on the text
display makes it appear on the screen; built-in character-
generating hardware takes care of the details. Similar hardware
exists on other PCs, but not on the Macintosh.
It was no oversight: by refusing to provide a built-in text
display, Apple's engineers forced developers to write programs
with graphic interfaces. There is no fallback, no "turn off the
graphics and run a command line" capability. Since the machine was
small, it also behooved developers to use the Mac OS for graphic
tools: there wasn't enough RAM to rewrite the menu or window
systems, so programmers had to use the built-in user interface
toolbox. However, forcing graphic programs meant that command-line
programs for Unix, CP/M, and DOS couldn't easily be ported to the
Macintosh, contributing to an "incompatible" aura that survived
for years. Given the choice between that and a slew of hastily-
ported non-graphic programs, Apple made the right choice.
Unix, you'll recall, had vastly different hardware requirements.
It supports multiple users on small computers. There is no graphic
display, and there is no mouse. In fact, Unix's _only_ definite
hardware requirements (other than whatever RAM and processing
power is sufficient for a given version of Unix) are:
* A text input device
* A text output device
Don't assume too much from this. A text input device is almost
always a keyboard, but a text output device can be a PC, a dumb
terminal, or even a printer. In fact, the earliest Unix users
often had to use actual teletype (TTY) devices, typing input and
seeing output only on paper. Obviously, CRT displays are a more
ecologically friendly option than going through a sheaf of paper
for every session. Either way, Unix itself does not even assume a
screen is present - just some way to display text.
**Text And Consequences**
The design is incredibly flexible, but its consequences are far-
reaching and determine the very flavor and experience of using
Unix. Text is not just one of Unix's data types, it is the core of
the system, the same way TCP/IP networking is the core of the
Internet. Unix fans, when pressed, point out that their OS deals
with binary data just as well as any other operating system, and
that's true: nothing in Unix _prevents_ it from handling binary
data, but the OS is designed to handle text.
**Total Keyboard Control** -- When the keyboard is your only input
device, it follows that everything you specify in the operating
system must be identified from the keyboard. That's a broader
statement than it appears to be at first blush. In the original
_Apple_Human_Interface_Guidelines_ for the desktop, Apple made a
big deal about how the graphic interface was a "see-and-point"
paradigm instead of the older, harder, "remember-and-type" system.
You have a window open, you see an object on which you want to
operate, you select it, and then you do something with it. You
click on a file to open it, you select a rectangle to change its
color, you select text to change its font, you choose a window to
close. In the command line world, you had to remember complex
commands and type them as well as the objects to which they
applied.
At the risk of being obvious, a command line can't work any other
way. The only guaranteed input device is a keyboard (OK, a "text
input device," but we'll pretend they're all keyboards to prevent
linguistic insanity), so the only way to specify a file is by
typing its name. The only way to specify a command is by typing
its name. Given these restrictions, typing command and filenames
is as simple as it gets. Yes, you have to remember the command
names, but you can use commands like man and apropros to jog your
memory. There's no way for Unix to keep a list of available
commands in front of you, as the Macintosh does with its menu bar,
so the command line is the best of the limited choices.
Many people rightfully see the desktop interface as a huge advance
over the command line, and in many ways they're right, but they
often fail to notice that Unix doesn't have the option of
_requiring_ a mouse. You can run the X Window system on top of
Unix, but X applications (not to be confused with Mac OS X
applications, one reason we're not abbreviating Apple's new
operating system as just "X") are kind of like Mac OS X
applications - they require the additional layer of the X Window
system above Unix itself and won't run without it. It's not quite
fair to compare Unix with the X Window system to Unix without it -
when you impose additional requirements, the story changes. Since
the X Window system is not part of Mac OS X (unless you add
something like Tenon's Xtools [54]), it likely won't affect your
use of Mac OS X.
[54] <
http://www.tenon.com/products/xtools/>
Take one of our command Macintosh vs. Unix examples of making an
alias. In the Mac OS, you'd point to a file and pick a menu item
(or press Command-M) to make an alias file that references the
original file you selected. You can move the alias file anywhere,
and you can move or rename the original file anywhere on the same
volume. The connection doesn't break. You can leave the original
file where it belongs while referencing it via the alias from
where you want. You can't take the Adobe Photoshop file out of its
normal folder or it loses track of all its plug-ins, but you can
put an alias to the application on your desktop for convenience.
You can open the alias instead of navigating to the Adobe
Photoshop folder to launch the program.
This makes no sense in Unix - if you had a Mac-style alias in one
directory, you'd simply be typing one pathname instead of another,
saving nothing. What would make sense in Unix is a way to create a
reference to a file in another directory in the place of your
choice - for example, a reference to something in a complex
directory stored as a simple file in your home directory. You
could type the shorter, local reference instead of the full remote
pathname. In fact, that's what Unix _links_ do - a link references
another file somewhere else just like a Mac OS alias does. The
difference? Unix links reference their targets only by pathname.
Moving the original target breaks these soft, or _symbolic_,
links. This is normally what Unix users want - links tend to be
for files that get replaced regularly, like log files or Unix
system files, and users want the links to point to the new file if
the old one has been deleted. Mac OS aliases would follow the old
file, even into the trash. (A Unix _hard_ link makes a new
directory entry for the target file, treating it as the file
itself and not a reference to it. It's like having the same file
in multiple directories. Even deleting one of the link references,
or the original file, doesn't break other hard links.)
Mac OS aliases abstract files beyond their simple pathnames. In
Unix, abstracting a file beyond a pathname doesn't make sense when
all files are specified by pathname. Mac OS X's Finder and other
applications add Mac OS-style aliases to the list of tools you
have available for managing your system, but in a pure Unix
system, they wouldn't make much sense. Even the word is confusing:
in classic Unix terminology, an _alias_ is a shortcut for a
command name that you set with the "alias" command. For example,
typing "alias lsetc 'ls /etc/'" creates a command such that typing
"lsetc" performs the command "ls /etc/" (listing the "/etc/"
directory). Type plain old "alias" to get a list of all installed
aliases for typing shortcuts.
**Text Is Everything** -- Ever wonder why there's no equivalent of
ResEdit for Unix, an editor lots of small preferences and data
structures? The answer comes from the text limitation. ResEdit on
Mac OS provides a user-editable view of binary data normally used
to configure windows, alert messages, and so on. In Unix, the only
guaranteed way to view data is a text display, usually a screen.
Why would the operating system, especially trying to stay small
and compact, implement something like a Resource Manager when it
would just take more code to access the data? If everything's
going to be edited in a text display, the most logical way to
store configuration information is in text files.
Unix has no equivalent of ResEdit, but choosing between available
text editors (like vi, pico, or emacs) is a religious issue among
Unix users. Think of how many Mac OS X tips you've already seen
advising you to edit a text file from the Terminal window to turn
some feature on or off: all of those are settings that might have
been stored in preference files or resources in Mac OS 9. Unix
veterans argue their way is better because the settings are
exposed and easy to change; Mac OS experts counter that since you
_can_ edit settings in text files, Unix programmers tend to leave
it that way instead of putting a real human interface on choices.
Mac OS X Server, for example, is already getting praise for its
ability to control Unix servers like Apache from a real
application instead of forcing you to edit a bunch of text files
and manually synchronize their settings. In the Mac OS tradition,
storing such settings in binary form pretty much forces developers
to provide you with an easy way to change them. Each way has its
benefits; both hail from early design decisions.
The Unix way of stringing several commands together depends on
text as well. When you redirect a text file into the "mail"
command so you don't have to retype it, you're relying on the fact
that mail expects text input. You can't redirect a JPEG file into
mail; you'd first have to use uuencode to turn it into ASCII so
you can E-mail it. Don't blame Unix for being narrow-minded here:
unlike MS-DOS, Unix pipes really are binary, and if you direct an
eight-bit binary file into a program, Unix happily provides all
eight bits of the data. Unfortunately, the mail command can't
handle it.
The uuencode command can, however, but it's more of the exception
than the rule. The output of uuencode is, by default, text (it's
like binhexing - the whole point is to change binary data into
ASCII text that can survive E-mail). By accepting binary input,
uuencode is a good Unix citizen - other commands may not write
binary output to feed directly into uuencode, but you can use file
redirection if you want for its input. The command string "cat
bom.txt | compress | uuencode bom.Z > bom.uu" dumps the text file
"bom.txt" into the compress command, takes the binary compressed
data output and feeds it to uuencode, and writes the uuencoded
output (text again) to the file "bom.uu".
Even though there is binary data in this flow, you can see that
most of it depends on text moving back and forth. If you just type
"compress bom.txt", compress does not write the binary output to
the display; it creates "bom.txt.Z" for the output. However, if
you force the issue through pipes, by typing "cat bom.txt |
compress", it _does_ dump binary data to the terminal, creating a
huge mess on-screen. You'll notice that when Unix commands start
handling binary data, they also start cheating on the input and
output model as compress does - dumping output to files by
default, or forcing an output filename, because displaying it
isn't an option. As long as you stick with text data, Unix's clean
redirection model shines. If you don't, commands have to jump
through hoops to keep binary data out of the standard input and
output channels.
**Working With Words** -- The Macintosh (and Windows after it) has
evolved several interface enhancements to make it easier to
manipulate icons and other objects on-screen. Window tunnelling,
pop-up menus in window title bars, pop-up windows, and contextual
menus are just some of the Finder features in Mac OS 9 that System
1.0 didn't have and that its engineers probably couldn't have
imagined. Actions like double-clicking and throwing disks into the
Trash that were originally intended as shortcuts are now standard
behaviors. Similarly, Unix has evolved in ways that ease the
burden of its primary interface: text input.
The Unix command line treats spaces as delimiters that separate
arguments; the command "cp System Folder", by default, tries to
copy the file "System" to the file "Folder". If you wanted to
refer to the actual folder named "System Folder", you'd have to
"escape" the space character with a backslash, as in "System\
Folder", to tell the command line interpreter to take the space
literally and not as a delimiter. Either that or put the entire
pathname in quotation marks for similar reasons. When you drag-
and-drop a file into a Terminal window, Mac OS X chooses to
single-quote the pathname; the shell's own filename completion
inserts backslashes. However, long-term Unix users normally don't
see these issues: since they know that putting spaces in pathnames
makes extra work when referring to the files, they just don't put
spaces in filenames. Sometimes it goes too far: Mac OS X has
problems handling passwords with spaces because, since Unix
entities normally don't have spaces in them, someone forgot that
they might.
Unix commands have short and cryptic names. _Think_Unix_ will tell
you this is because shorter names save memory, but that's a bit of
a stretch. The truth is that shorter commands are easier to type:
"ls" is loads easier than "listdirectory", "pwd" is shorter than
"printcurrentdirectory", and so forth. Unix has grown dependent
upon its standard directory structure not only for conformity, but
because so many people have learned it that it would require a lot
of retraining to change it for not much benefit. It would be like
changing the Mac OS Finder to start putting hard drive icons
across the top of the screen - no one expects it and it doesn't
buy you anything, so why change it?
The Mac OS Finder allows you to select multiple files easily, and
most programs have similar mass-operation capabilities (like
Select All, Shift-click, Command-click, and other specific ways to
extend selections). Unix also has convenient ways to avoid typing
multiple filenames: wildcards and other special characters are
interpreted by the operating system to expand patterns, called
_filename_globbing_ for the traditional no-good reason. Many
casual Unix users know that "*" in a filename expands to match
zero or more characters, and that "?" matches a single character
in that position. The pattern "file*.txt" would match
"filename.txt", "files.txt", and "file.txt" but not
"filmnoir.txt"; the pattern "fil?*.txt" would match all of these
filenames.
Here again, we see why something that is a pain to Macintosh users
makes perfect sense in Unix. Filenames are typically overloaded; a
three-character extension substitutes for a real file type. This
is horribly annoying in that, as we've pointed out, sometimes just
renaming a file makes Mac OS X think the data inside it is of a
different type. From a command-line perspective, however, it's
very handy: the expression "*.txt" matches all text files; "*.jpg"
matches all JPEG images, and so forth. Unix users have no Finder;
they can't click on "View By Kind" and drag to select everything
that floats to the right part of the list. File types _are_ handy
to Unix users, but since their only file selection tools work
exclusively with filenames, putting the file type in the filename
makes sense. It's only when you move beyond a command-line
requirement that the limitations start to chafe.
You might also imagine that since Unix forces typing filenames,
its tools for manipulating those names are remarkably solid. The
Finder falls far short of Unix in allowing you to select files
based on criteria: unless you can sort a list by the criteria and
drag-select the files you want, you're kind of out of luck. Frank
Reiff's popular "A Better Finder" series [55] of contextual menu
modules addresses that very issue by borrowing hints from Unix: A
Better Finder Select lets you specify Unix-style criteria for
picking filenames, including the equivalents of "*.txt",
"page??.html", and lots more. A Better Finder Rename allows
quickly renaming batches of files according to rules, instead of
clicking and typing on dozens of icon names in turn. Some expert
users are happy to have a command line in Mac OS X specifically so
they can access these great filename manipulation capabilities,
but we're still hopeful an interface more like Reiff's catches on
instead of the default "Hey, you have a command line, use it"
attitude.
[55] <
http://www.publicspace.net/ABetterFinderSeries/index.html>
**The New Shell Game**
The core of most Unix interfaces is the _shell_, the program that
provides the command line interface. You can't run a standard Unix
installation without a shell; whether or not the system actually
takes you to a command line prompt, there must be a shell
installed and ready to run because the design of Unix allows
commands to call upon it. In Mac OS X, you can launch the
ProcessViewer utility to view all running processes, including the
background-only Unix applications that keep the system running. If
you filter it to just show "Administrator Processes," you'll see,
down at the very bottom, using about 168 bytes of physical RAM, a
process named "init". It is init that launches Unix's multiple-
user capability by executing "reboot" scripts; if they fail, you
get Unix's built-in, default, unfriendly single-user mode at a
local console (the same one you can get in Mac OS X by holding
down Command-S as you startup). The init process starts looking
for logins by executing commands in the "/private/etc/ttys" file.
In Mac OS X, that file is altered from standard Unix to run the
LoginWindow application instead of just prompting for "login:" on
a text screen. When you log out, "init" gets control again and
starts the process over. Its man page says, "The role of init is
so critical that if it dies, the system will reboot itself
automatically. If, at bootstrap time, the init process cannot be
located, the system will panic."
Since Mac OS X spawns LoginWindow by default, you normally won't
see the actual shell in ProcessViewer unless you have a Terminal
window open. If you do, though, you'll see tcsh in the list, just
as you see "/bin/tcsh" in the title of the Terminal window. Mac OS
X's default shell is _tcsh_, a name that makes sense only with a
bit of history. The original shell in Unix is, true to form, named
_shell_. Over the years, programmers started replacing it with
their own versions. Around 1978, Stephen Bourne of AT&T Labs in
New Jersey wrote his own shell, the Bourne shell, found on systems
today as _sh_. The Bourne shell offers advanced scripting for
automating what Jon Lasser calls "relatively complex" tasks.
Meanwhile, across the country, those rebels in Berkeley led by
Bill Joy (later to create much of Java at Sun) wrote a new shell
that offered advanced job control. Since Unix has no application
menu or dumb-ass Dock to use for process management, the shell has
to provide the tools (or at least access to the tools) for
bringing processes to the front, making them run in the
background, terminating wayward programs, and so on. Joy's shell
offered that, along with enhanced redirection and piping, and a
shell scripting language that shared a lot with the "C"
programming language, leading to that shell's name: the C Shell
(_csh_).
Of course, this hardly ended it. Just as every week brings new
Macintosh utilities to change file types or store passwords, more
shells were written. We won't cover the Korn Shell [56] (_ksh_)
here; it's not installed in Mac OS X. In later years, a new shell
was written based on the Bourne shell's syntax but adding the
redirection and job control of csh; it's called the Bourne Again
Shell [57], or _bash_, and is the default shell on most
installations of Linux. Meanwhile, csh got enhanced with better
scripting and command-line editing, including several features of
TENEX and TOPS-20 [58], adding a "t" to csh and creating tcsh.
[56] <
http://www.oreilly.com/catalog/korn/>
[57] <
http://www.oreilly.com/catalog/bash2/>
[58] <
http://home.frii.com/support/t.html>
All shells are not alike, and even though bash is the preferred
shell among the command-line cognoscenti today, Apple had good
reason to choose tcsh instead. The more scripting-oriented bash is
a good choice for systems like Linux where the primary interface
is the command line. Its users will likely write more shell
scripts (and benefit from advanced parts of bash designed for
automation). Meanwhile, since Mac OS X's philosophy is that you
won't _have_ to open a terminal window, tcsh is a good choice
because it provides extensive typing shortcuts and command-line
editing. In Mac OS X, you'll more likely use AppleScript to link
applications together for complex tasks; Unix shell scripting is
powerful, but it's never going to let you take output from
Photoshop and automatically place it in a QuarkXPress layout.
You're more likely to use the Mac OS X shell for small tasks that
need command-line power, and tcsh helps you avoid typing if you
learn its lingo.
**Your Ultimate Shell Secret** -- Once we unveil this, it won't
stay secret for long, because it works. If you intend to spend a
fair amount of time in Mac OS X's Terminal window, spend US$30 for
the O'Reilly & Associates book Using csh & tcsh [59]. It's an
older volume, from August 1995, but neither csh nor tcsh has
changed that much since then. These Joy-derived shells are chock-
full of ways to avoid repetition at the keyboard and to keep you
from typing those complex quoted or escaped filenames. Taking full
advantage of the power of tcsh requires a learning commitment on
your part, but that's not the issue. If you know you _will_ be
spending time on the command line, would you rather do it
efficiently or stumble through it?
[59] <
http://www.oreilly.com/catalog/tcsh/>
Shells like tcsh are, to Unix purists, the human interface; it's
no surprise they've evolved to minimize typing requirements for
experts. Programmers know this; they learn the Command keys for
the CodeWarrior IDE or BBEdit editors by heart so they can work as
fast as possible. Authors who use Word on a daily basis learn the
fastest ways to get to the commands they use instead of browsing
through acres of menus or toolbars. Shell users learn Control-key
combinations and somewhat-bizarre syntax to speed their tasks as
well.
For example, don't type long filenames in the shell. When you have
a file or pathname argument on the command line, type the first
few letters of it and hit the Tab key; tcsh expands it to the
first filename or pathname that fits the bill. If more than one
does, you get a list of matching names so you can type enough
characters to specify it. tcsh also escapes characters for you; in
your home directory, type "ls Net" and hit the Tab key and you'll
see it expand to "Network\ Trash\ Folder/" (with the final slash
indicating a directory, just like "Music/"), nicely escaped. tcsh
doesn't quote these filenames because that might interfere with
complex commands.
Press the up-arrow and down-arrow keys to cycle through commands
you've typed. The "history" command shows you all the commands
you've issued (even across sessions), and tcsh provides a huge
number of commands for reusing previously-issued commands. "!!"
reissues the last command. "!15" reissues the command numbered 15
in the history list. "!grep:s/mdj/mwj" repeats the last command
that started with the letters "grep", replacing the text "mdj" in
the command with "mwj". tcsh happily echoes the modified command
line so you can see what you're doing. If you learn the structure,
you can even type a few characters to reference specific arguments
from commands far back in your history buffer.
tcsh offers spelling correction; by default, if you type "lls"
(which is not a command), tcsh asks if you really meant to type
"ls" for listing a directory. You can control how that works. You
can even add your own rules for completing commands you type
frequently, telling tcsh what to do when you type part of a
command and press Tab. You can make the command line work like a
miniature version of either vi or emacs (respecting either
editor's key assignments).
Just a few of these tips can save you beaucoup time. If you type a
complex command with an error in it, knowing you can press up-
arrow to get it back on the command line and edit it is already a
big win. If you only misspelled a folder name, like "Destkop",
it's even easier to just type "^Destkop^Desktop" and let tcsh do
the editing for you (admit it, how many times have you wanted a
Mac OS application to bring back a complex dialog box with all of
the previous settings because you screwed up one of them, like
forgetting to pick manual feed when printing?). If you get enough
into it, you can even tell tcsh to pick up a complex command you
typed several minutes ago, change some arguments, and reissue it,
all by typing just a few characters.
Again, the question isn't whether you think you should have to do
this to use Mac OS X. You shouldn't and you don't. However, this
whole bit about "the power of Unix and the friendliness of
Macintosh" necessarily means that, from time to time, you may want
to install Unix software that has no Aqua interface. If such
software becomes a part of your daily routine, the command line
may as well, at least until enough people pound on the developers
(or the open-source community) to put a friendly, scriptable
interface on it. You can happily ignore Unix-only programs in Mac
OS X the vast majority of the time. If you want to avoid the
command line, you can restrict your use to the occasional
troubleshooting session. But if you find the command line a
powerful tool, it makes sense to learn its ways rather than fight
it. Don't spend more than casual time in Terminal without the
O'Reilly book; if you're going to learn how to use tcsh, do it
right.
**The Big Picture**
We think Unix's text-based hardware requirements are secondary
because, unlike the effects of a multiple user operating system,
you can largely avoid text issues until you get to expert-level
control. All Mac OS X users have to address login issues, file
permissions, preemptive multitasking, and other consequences of
the multiple-user design. In most cases, you won't see text input
or output at all unless you choose a utility based on it, like
Terminal or Console. (If you want a real lesson in how Unix
behaves, keep the Console utility open: Unix programs that expect
a way to output text error messages funnel them through Console in
Mac OS X, and you'll often be surprised at the kind of detritus
dumped into it.)
Do not mistake an understanding of Unix with acquiescence. Because
we know how Unix evolved, we understand the necessity of multiple
users and file permissions, but we don't accept for a minute that
the command line is the management tool of choice. It's a huge
omission that the Mac OS X Finder doesn't allow you to change the
owner or group of files and folders, one we hope Apple corrects in
the next significant release of Mac OS X. Finder could also use
better privilege management tools. The "Info" window pop-up menus
were fine for shared folders on file servers, but when every
single folder and file has its own privileges - and when software
may not work properly if they're not set correctly - it's
necessary to provide better tools for managing large sets of
privileges.
It's the multiple-user heritage that shows through most clearly in
Mac OS X, and the text-based requirements that make classic Unix
hard to use. Mac OS X does a pretty good job now of overcoming
that secondary directive, and we're sure it will get even better
in future releases. The primary effects of a multiple user
architecture, however, are going to be with Mac OS X forever.
That's not a bad thing, though it does introduce complexity into a
system that was originally lucky to manage a five-page document
for a single user at once. The challenge for the next year is
preserving the value and power of Unix in Mac OS X while adapting
its traditional elements to suit Macintosh customers. With a login
window replacing a shell prompt, the addition of Macintosh
behaviors onto a text-based system, and the relegation of text
limitations to the background, it's a good start. No more, no
less.
In the meantime, grab _Think_Unix_ (and, if you want more
information, _Learning_the_UNIX_Operating_System_ and
_UNIX_In_A_Nutshell_) to understand the concepts more thoroughly.
If you _choose_ to leverage the Unix portions of Mac OS X, do
yourself a favor and learn how to do it effectively without making
it your computer life.
--
How long until Apple abandons the clunky "keyboard/Mouse combo" for the
iTelepathic Cranium Input device? A: 2013 (Unfortunately the earth will
be ruled by the dirty apes, and Steve will be replaced by an angry
chimp in a black turtle neck) -You mean Larry Ellison will be iCEO?