Don Bruder <dakidd@[EMAIL PROTECTED]
> wrote:
# In article <135qa6897ko7h6c@[EMAIL PROTECTED]
>,
# SM Ryan <wyrmwif@[EMAIL PROTECTED]
> wrote:
#
# > # The good news is that I always know the file's path:
# > # "/Users/LoginName/Client.log", so I can easily pass it to
# > # FSPathMakeRef() to get an FSRef to work with.
# >
# > char fpath[] = "%s/Client.log";
# > char path[sizeof fpath+strlen(homedirectory)];
# > sprintf(path,fpath,homedirectory);
# >
# > FSRef is evil.
#
# OK, I'll play along... Why is FSRef evil? Please be specific and
# convincing.
Because you're working on Unix now, and it's time to get into the
1970s. Unix has two simple ways to identify a file, either or both
of which are available on nearly all system calls: the file path
(char*) and the open file descriptor (int). Any complexity of
interpretting the path are left to the kernel. FSRef is a redress
of FSSpec which was little more than an HFS directory entry. It's
a baroque interface to provide backwards compatiability with System
6 era HFS code rather than leverage new capabilities on top of
the Unix path.
It looks like Cocoa is about leveraging on the Unix kernel instead
of System 1 interfaces. (I don't use Cocoa that much yet until
Apple sup****ts garbage collection in objc.)
# Personally, I find that they're rather convenient. Much more so than
# going through the unix gyrations you suggest. (and without needing to
# worry about setuid and/or daemon-related "uh-oh"s, and similar weirdness
# that you mentioned later in your post.)
The other routines are other using getuid/getpwuid, or some
ProcessManager abortion. If they are using getuid, the same
considerations apply whether you are aware of it or not. So
you might as well be aware of it.
If they are using ProcessManager, that can bite you if you ever
need to write daemons. Daemon operate outside ProcessManager
and as of 10.4 Apple has a number of arbitrary barriers between
traditional Unix processes and ProcessManager processes. For example,
Applescript cannot (or at least could not into 10.4) run in daemons.
That means things like osascript can be used in Terminal, but the
identical command will (or would) fail in an Apache CGI script.
# Another poster suggested, and now that I know about it, I'll be using,
# the Carbon function "FSFindFolder()", which gives me exactly what I'm
# looking for (Namely, the FSRef of the user's home directory, which I can
# then graft the filename onto with an amount of heartburn that closely
# approaches zero) in a single call. If that's "evil", mark me down as
# part of the "brotherhood of evil coders" :)
In Unix that's called tilde expansion which replace ~ with the home
directory of the current uid, and ~username with a specified user.
It's not done by the kernel, but there are plenty of libraries that
do it for you if you want. If you want to write programs that can be
with minimal pain to other Unices, learn the Unix way. Carbon locks
you into Apple only.
Besides doing it the Unix way means everybody writing free libraries
for Linux, BSD, and Solaris are also writing free libraries for you
on MacOSX.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
So basically, you just trace.
|
