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: David Masover <email@hidden>
- Date: Thu, 20 Jul 2006 22:41:59 -0500
Steve Checkoway wrote:
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.)
And they also have an annoying habit of treating anything after the
files as a file itself. This just bugs the hell out of me:
eve:~ sanity$ mkdir -p a/b
eve:~ sanity$ rm a -rf
rm: a: is a directory
rm: -rf: No such file or directory
eve:~ sanity$ rm -rf a
eve:~ sanity$
I'm sure there's some standard library you can use to fix that, and if
you really want to force '-rf' to be interpreted as a file, you can do
rm ./-rf
or
rm -- -rf
Although these are just what I'm used to from Gnu, I don't know which
ones work with the BSD ones.
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
I have a fair idea of how Reiser4 works, and how filesystems work in
general. As far as I can tell, the filesystem doesn't care how deep you
nest your directories, and names (without the path) can be very large (4
megs, I think, maybe more) -- but you run into problems with almost any
program that ever makes the mistake of tripping the absolute path --
bash being just one example. Also, you will eventually run out of inode
numbers, or whatever the equivalent is -- there is a limit to the number
of files you can have, so with any filesystem today, even a completely
relative equivalent of this will eventually fail:
$ while mkdir a; do cd a; done
This is all basically a consequence of working in C, for speed, versus
working in a language like Ruby, which will grow numbers as big as you
like, it just starts using the Bignum library after awhile. But even
that has got to have a theoretical limit. After all, how big can your
address get?
But real-world computer systems tend to keep us one step ahead of having
to program for theoretical infinity. Look at the difference between
32-bit and 64-bit addressing...
as you'd like. You could probably hard link directories into a loop but
that's very very bad.
eve:~ sanity$ mkdir a
eve:~ sanity$ ln a b
ln: a: Is a directory
eve:~ sanity$
That's standard behavior, by the way. You can't hardlink directories
for exactly that reason -- you never know if you're creating a loop.
This was actually a problem the Reiser4 guys had awhile back. They were
trying to unify the namespace a bit by saying that every file can act
like a directory and vice versa. Interesting stuff, and I don't
remember exactly how they solved it. I think one solution involved
having each directory store a list of pointers to its parents, so you
avoided ever creating a loop. Another one disallowed pointers to files
which can contain regular files, since most files-acting-as-directories
only contain pseudofiles (which are metadata). And then there were
really strange ideas like garbage collection and various methods of
trying to actually successfully remove a loop of hardlinks.
Anyway, it's been a couple of years, and I've lost touch, but it's
amazing how far you can take the old Unix concept of "everything is a file".
But if you want to play with some silly loops right now, try this:
eve:~ sanity$ ln -s . a
eve:~ sanity$ cd a/a/a/a/a
eve:~/a/a/a/a/a sanity$ cd
eve:~ sanity$ rm a
eve:~ sanity$ ln -s a a
eve:~ sanity$ ls a
a
eve:~ sanity$ ls -lh a
lrwxr-xr-x 1 sanity sanity 1B Jul 20 22:25 a -> a
eve:~ sanity$ cat a
cat: a: Too many levels of symbolic links
eve:~ sanity$ cd a
-bash: cd: a: Too many levels of symbolic links
eve:~ sanity$
Of course, symbolic links don't really count...
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.
Fair enough, but even with limits like 1024, the problems regarding iDVD
are most likely not the length of the filename, but someone hardcoding
it somewhere.
In any case, why would a Carbon or Cocoa call change that? I know of
several Unix apps that work that way -- start them off with a working
directory that includes most of the resources they'll need, and they can
just use the working dir for everything else. Maybe they're storing the
actual path somewhere under the hood that I don't know of...
Of course, once you actually go to Unix, you find a lot more paths are
often hardcoded, except this is a good thing. /usr/lib, /etc, /tmp,
/var, and so on. Often configurable, but even if they aren't, you can
always chroot it if you have a reason to force it to live somewhere else.
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.
That's the idea -- hence Gnu's Not Unix (but it is, kind of)
By the same token, I'm glad Mac OS X isn't really Mac OS Ten, because I
would hate nothing more than to program for the true successor to OS 9.
_______________________________________________
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