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: Steve Checkoway <email@hidden>
- Date: Thu, 20 Jul 2006 19:58:39 -0700
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
eve:~ sanity$ rm -rf pathtest/
eve:~ sanity$
The "rm" command, a standard Unix utility which I can't imagine has
had one line changed since BSD or Linux, managed to go far deeper
into that tree than Bash would, in order to rmdir all its
children. I think that path goes about 10 more directories deep,
and I'm sure Spotlight had no problem with it.
OS X would use the BSD one. (Those are the ones that don't respond to
the "standard" options like --version that GNU insists on.)
My guess is that they either chdir(2)ed into each directory or used fts.
Interestingly, my Linux machine (connected to with SSH), running
Reiser4, doesn't have this problem at all. So maybe it's not bash.
My guess is that's a system limit, not even a file system limit. I
don't know how HFS+ works, but usually directory entries can be
nested as far as you'd like. You could probably hard link directories
into a loop but that's very very bad.
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, and
much safer than the common Windows limit of 256 characters, which
you might reasonably hit with a single filename.
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.
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.
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."
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.
--
Steve Checkoway
1. D. M. Ritchie and K. Thompson, The UNIX Time-Sharing System,
Communications of the ACM, Vol. 17, No. 7, July 1974, pp. 365-375
<http://portal.acm.org/ft_gateway.cfm?
id=361061&type=pdf&dl=GUIDE&dl=ACM&CFID=12481107&CFTOKEN=18896699>.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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