Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year)
Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year)
- Subject: Re: Setting up searches in Xcode (Re: [ANN] Xcode + Leopard at WWDCthis year)
- From: Laurence Harris <email@hidden>
- Date: Fri, 21 Jul 2006 14:12:36 -0400
Responding to David and Steve:
On Jul 20, 2006, at 10:58 PM, Steve Checkoway wrote:
On Jul 20, 2006, at 7:31 PM, David Masover wrote:
Laurence Harris wrote:
That's bad app design -- use relative, configurable paths, not
absolute paths. Besides, one of the major points of Unix is that
paths don't necessarily correspond to real, physical locations.
and for problems to occur if a path is too long.
Hmm. You're right:
[...]
It would appear that this is the limit, either in number of
directories or sheer filename length. Still, I can't see hitting
that limit anytime soon. Also, it would appear to be a limitation
of the software, not the system or the concept:
A quick grep of the system headers returns this:
$ egrep 'PATH_?MAX|MAX_?PATH' /usr/include/sys/{syslimits,param}.h
/usr/include/sys/syslimits.h:#define PATH_MAX
1024 /* max bytes in pathname */
/usr/include/sys/param.h: * MAXPATHLEN defines the longest
permissable path length after expanding
/usr/include/sys/param.h:#define MAXPATHLEN PATH_MAX
Path-based APIs fail when paths get too long. Given that names in Mac
OS X can be up 255 characters long, that some people like to use a
deeper directory structure than others, and that as I understand it,
Unicode characters can expand to at least three UTF-8 characters
(can't remember the max off the top of my head), this limitation can
cause problems in the real world. I realize they aren't common, but
it's my position that they simply should never occur. 25 years ago
this limitation might have made sense. Today it's just another
outdated aspect of Unix. If I have a multi-thousand dollar computer
with Gigs of RAM and a 100GB hard drive, I never *ever* want the
system to tell me I can't create a folder because there would be too
many characters in the path. Ever. It's long past time for the Unix
community to move into the present in this regard (and others IMO),
at least on the Mac.
So, lots of poor application design, but there's no really good
reason not to use or support names that insanely long.
In any case, it's far longer than anyone will ever have to use,
I don't think you can guarantee that. One thing I've learned in the
more than 10 years I've been doing a file utility is that Mac users
can be doing virtually anything you can imagine. Long names, Unicode
characters, deeply nested folders, hundreds of thousands of files
such as images, and so on. It's virtually impossible to predict what
users will want to do, and it's usually a mistake to assume they
won't need or want to do this or that thing.
I organize my Applications folder into subfolders. I remember the
first time I played with iDVD and tried to run its tutorial.
Because I'd moved iDVD into Applications/Media, iDVD couldn't
find its tutorial which was in its own bundle.
Another example of absolute vs. relative, and poor app design. An
Application bundle is designed specifically to let programs depend
on relative paths.
The two apis I mentioned both give absolute paths though since the
notion of the current working directory is fuzzier and I know of no
guarantee that it won't change due to Carbon or Cocoa calls,
especially anything working with the file system. I find that it's
nearly always best to just do that stuff using the system calls
directly.
And you can't use working directory tricks when storing persistent
references on disk.
I've also seen Software Updater crash because an application
wasn't in the Applications folder. I think they've fixed it now,
but I remember when I used to drag certain applications out of
their subfolders back up into Applications before running
Software Updater just so it wouldn't crash.
This is actually pretty fair. How would you propose that Software
Updater find the applications it's trying to update? Maybe it
could have links to them somewhere... like some, I don't know,
PATH inside its configuration directory?
Actually, you can ask for the location of an application. I'm not
entirely sure how it works and it might require that the app be
launched from the new location first. Most of the code I write is
portable so I've never depended on that.
You can use Launch Services to locate an application by its bundle ID
or search for it using FSCatalogSearch, or less robustly, you could
iterate over the contents of the Applications folder, but in practice
using Launch Services with the application's bundle ID is what I'd
use now. In the past, before bundle IDs, the usual practice was to
search the disk.
They're an improvement the Unix and Cocoa folks dumped upon us
because they rely on paths.
Allow me to quote an old Usenet signature:
"Those who do not understand Unix are condemned to reinvent it,
poorly."
Feel free to quote this as well: "Those who do not understand the Mac
OS are condemned to reinvent it, poorly."
You're very much a Unix guy. Allow me to point out that no one stuck
the Mac OS on top of your previous flavor of Unix and forced you to
deal with it. If you love Unix you can still use it without the Mac
OS. In fact, if you just woke up from a coma after 15 years you could
probably use it exactly the same as you did before. ;-)
OTOH, Apple built Mac OS X on top of Unix, so there's no way to avoid
Unix completely if you use a halfway recent version of the Mac OS.
And let's be perfectly clear on the fact that the bulk of the people
buying Macs are not Unix gurus, they're ordinary folk who can't even
spell eunuchs and think terminal is a disease you don't want. Those
are the people most of us want to keep happy because they buy the
vast majority of the software sold and the hardware as well. From
that standpoint it doesn't matter what Unix users like or even
programmers, because we aren't a very big share of the market. That's
why -- sadly -- there's no money to be made in Mac developer tools. ;-)
I'm happy we're not using UNIX as originally described in "The UNIX
Time-Sharing System" [1] but after being exposed to UNIX with OS X,
I've found that the ideas that came from UNIX have improved my
productivity immensely.
It's not my intention to say that Unix brought nothing of value to
the Mac OS, only to point out that some aspects of it can negatively
impact the user experience for mainstream Mac users and, more
importantly, that thinking like a Unix programmer is probably not
going to lead to the best result when designing Mac software.
Larry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden