Personally, I think the Mac OS X unix userland is rotten. There are apple tools mixed with some current unix tools and there are outdated unix tools like locate. Maybe you didn’t even notice that but locate for example doesn’t even know the -i option for case insensitive lookups in the locate.datbase. As usual, you can help yourself with MacPorts. Simply install the GNU coreutils and findutils. For convenience provide the +with_default_names option. If you don’t add this option you get glocate instead of locate and so on. Now the new locate can’t find anything unless you run updatedb from /opt/local/bin/updatedb. After that everything should be fine. Checkout what tools are included in coreutils and findutils by clicking on the equivalent hyperlinks. This resolves the weird behavior of tools on OS X that you might expect to work like on your FreeBSD or Linux machines.
Install coreutils (the -c option is equivalent to sudo port clean portname):
sudo port -c install coreutils +with_default_names
sudo port -c install findutils +with_default_names
Locate before the installation:
man locate
LOCATE(1) BSD General Commands Manual LOCATE(1)
NAME
locate -- find files
SYNOPSIS
locate pattern
DESCRIPTION…
and afterwards:
LOCATE(1) LOCATE(1)
NAME
locate - list files in databases that match a pattern
SYNOPSIS
locate [-d path | --database=path] [-e | -E | --[non-]existing] [-i |
--ignore-case] [-0 | --null] [-c | --count] [-w | --wholename] |-b |
--basename] [-l N | --limit=N] [-S | --statistics] [-r | --regex ]
[--max-database-age D] [-P | -H | --nofollow] [-L | --follow] [--ver-
sion] [-A | --all] [-p | --print] [--help] pattern...
DESCRIPTION…
I think you get the idea.
Can the GNU locate binary read the database built by the previously-installed locate? If not, it should be able to; mail me about it.
Hey there,
I just found your comment.
Right after the install of findutils, gnu loctate which was installed in /opt/local/bin/ didn’t find anything. I ran locate with the -d option and pointed to the “old” locate database in var/db which worked but it wasn’t permanent. I had to supply the option everytime. Then I found in locates manpage that I could run updatedb I ran that one. I thought either that creates a new databse in the right location or it will find the original database. I think the latter worked because I still only got the database in /private/var/db/locate.database. Afterwards gnu locate worked as expected without the -d option.
Hope that was some help.
How did you find my post by the way ?
I totally agree about the MacOS X unix userland being rotten. But I’d like to warn you and your readers about a problem you’ll be running into when you replace the userland:
Although they tried in the beginning of OS X, Apple never dropped the resource forks. In most cases they’re used only to store data needed for ludicrous features, like colour labels and so on, but sometimes OS X stores data within the resource fork you might not want to loose (e.g. Bookmarks you drop from Safari to the Finder). I made this experience when I last needed to restore from backup, which I used to make with rsync. It turned out that rsync can’t handle resource forks. I also tried ‘Rsync X’, which can handle resource forks but turned out to be incompatible with any other rsync. Welcome to vendor-lock-in!
Parts of the OS X userland can handle resource forks since Tiger (well, the core can, ‘cp’, ‘mv’ and some other programmes, others can’t), but unfortunately the userland you generate from MacPorts can’t. You can test this easily: give a colour label to an arbitrary file and then copy that file with the new ‘cp’ you’ve build with MacPorts. On the new copy the label will be gone, as does the whole resource fork. Try this with one of Finder’s aliases – it will break (unix symlinks or even hardlinks are better anyway), so will other files. You’ll have to find out yourself which kind of files will be damaged or destroyed when you loose them their resource forks and whether they’re expandable for you, I’ve pretty much given up on it.
So, as usual with Apple, you’re heading for major pain. I’ve used Apple for over ten years now and got quite used to it, funny isn’t it?
That was meant to read ‘expendable’ not ‘expandable’ of course. Sorry.
This is actually a valid point. Although, since all the macport tools are installed in /opt, you can still use the regular rsync or cp in critical situations. Therefor you would have to type the whole path to the original binary, like /bin/cp but thats okay for me.
The good news is that leopard ships with a more up to date userland. So if you guys are not sure about compiling your own locate, wait till october.
Thanks a lot. After upgrading to Leopard, was having problems with finding coreutils’ date. Now coreutils has installed it as gdate (found it after a lot of googling). You answered my doubt about that.
Happy new year.