Sometimes one needs to know what package a given file belongs to. Such information is contained in Archive.bom files that are added under the /Library/Recepits directory every time a package is installed. However, it's impractical to scan this folder for all Archive.bom files.

The findutils tool locate can be used to perform the task of mapping files to packages in a much more convenient way. It's enough to build a databse containing the required information in a format that locate is able to use, and then point locate to such database.

The database will contain a tab-separated list of file/package names; to produce such list we use find to obtain the list of all Archive.bom files, lsbom to list their contents, and a bit of bash magic to paste the file and package name. Once we have the list, we just need to sort it and to front-code it (using the frcode tool, from findutils).

With the recent advent of a possible Mac OS X virus (or trojan, depending on who you ask) many OS X users are wondering how safe they really are. Those "infected" by the so called virus are currently clueless as to what the virus has really done. Luckily, UNIX has a tool that may help find it.

The du command (disk usage) is capable of printing out a list of all the files on your Mac. Redirecting its output, you basically have a giant log of all of your files at any given time. If you do this on a regular basis, and compare the old with the new, you suddenly can see what has changed (ie: where is a virus?).

So, do this, I whipped up a little shell script. Note that I am not great with scripts, but I have tested this, and it works for me (on at least 10.4). Make a script called duscript.sh, and save it in your Home directory. This is the script:

#!/bin/sh
cd /

du > ~/duLog-`date +%Y%m%d` &

Make sure to make the file executable by typing chmod +x duscript.sh. Then, add the file to cron. I used CronniX to do this.

In CronniX, choose File: Open System Crontab. Then, click the New button in the main window. Click the Expert tab. In the below textboxes, set it to run however often you want. I have mine to run every day, at 6 PM. For Day, Day of Week, and Month, I have it set to *, and for hour, 18. You can set it to run however often you want. Then click the Browse button and select your script.

That should do it for you. The script will run in the background on your specified terms, and it will give you logs to work with if (heaven forbid) you need to clean up from a virus.

[robg adds: While this works, it will generate very large files. In a test on my G5, I wound up with a file that was nearly 20MB in size and took about 15 minutes to execute. Comparing two such files won't be very pleasant, even using FileMerge or diff.

However, given the recent activities in the malware/trojan area, I think that discussing ways to track changes to your system is an important one. Read the rest of the hint for my thoughts on one alternative method of tracking such changes...

Having spent €39 on TextMate and a similar amount on Transmit, I felt quite happy with my development environment. However, once an emacs user, always an emacs user (and it doesn't help that TextMate has mediocre python support, either).

I still like Transmit, though, and wanted to use it from within emacs. After some fumbling and gnashing of teeth, I came up with this solution. Note that this requires a registered version of Transmit ~2.5 or newer.

First of all this is not my code, I found it on this page via Google, while looking for something that would work like the 'tree' command in Windows.

This guy found a way to do so, using just ls, grep and sed; pretty neat! Here's the command:


The author of this useful command even provides a downloadable shell script for the code, and explains how to make a link to ~/bin/tree for those less Unix savvy users. Enjoy!

[robg adds: First, I apologize for the scrolling box, but I didn't want to take any chances on changing the format of the command by inserting a line break, and it was otherwise too wide for display. I'll be the first to admit I don't understand anything in that command past the colon-replacement bit, but it does work quite nicely. Here's a sample of the output, using the shell script from the linked page:

$ tree /Applications | more
/Applications
   |-Address Book.app
   |---Contents
   |-----MacOS
   |-----Resources
   |-------ABLargeTypeWindow.nib
   etc...

You may wish to add | more at the end to page through the output. Or try using > ~/Desktop/mytree.txt at the end to dump the output to a file. I do not, however, recommend doing that with a huge directory such as Applications, unless you have some time to wait. I tried it, and after a few minutes of waiting, wound up with a 1.1mb text file containing 37,000+ rows!]

This seems pretty old, but I just came accross it. It looks like the OpenDarwin group has created binaries for installing KDE specific apps on OS X (the source files are also accessible elsewhere). Just visit kde.opendarwin.org/.

You need to install at least the Qt, kdesupport and kdelibs packages to begin with, so the rest of the packages will work. From there on, I also recommend kdebase and kdenetwork. Through these two packages, I have a working version of the Konqueror browser on my OS X, with all the nice protocol support (such as fish://) that comes with it.

Bugs galore, as development has stopped on these versions in favor of completing KDE4 first, and then trying to port that ... but they still work! I've managed to get them to run on OS X 10.4.4 without many problems (even though the site states that the binaries were compiled on Jaguar), and most of the apps that come with the packages seem to operate just fine (more or less -- see note below). Kile (a LaTeX front end) has a lot of niceness, and I'm experimenting with Kate (which is slow on my system, but I think I can tweak it to run satisfactorily).

I suggest using the second option on that page to download, unless you're on a really fast broadband connection, as there are over 200 megs of binaries to download if you want the full package! (I like the progress bar to know where I'm at.)

Note: As mentioned on the above linked website, these apps sometimes have problems shutting down (they don't die gracefully). To combat that, I wrote a small Terminal script that cleans up memory from all (runaway or not) KDE processes. Other than that, no Terminal usage is necessary to install/play with these applications! Copy the following snippet, save it in a location you can easily access from the Terminal, and then type chmod 755 filename to make it executable:

#!/bin/bash<br />
kill `ps aux | grep kde | grep -v grep | awk '{print $2}'`

That's it! If you name the file killkde, and you save it in your home folder, all you have to do is start the Terminal and type ./killkde to terminate all running KDE apps.

If you cannot login any longer from your Mac user's shell account to a remote server with ssh, and ssh -vvv loginname@server is hanging at the following line...

debug3: Trying to reverse map address 192.168.73.23.

..then look cd into /tmp/.KerberosLogin-xxx-yyyyy, where xxx is your Unix user ID (typically 501 for the first user created on the machine), and yyyy is a random number. Once there, remove the file named KLLCCache.lock. Try again, and bingo. Hurray!

[robg adds: On my machine, these directories also have some text following their names -- (inited,gui,tty,local), for instance.]

There's an existing hint about using x-man-page URLs to link to Unix man pages. When such a URL is clicked, it opens in Terminal, which automatically invokes the man page for the linked command. For example, something like this: View ls manpage.

But there's another element to this, not covered in the original hint: you can also specify the section. For example, x-man-page://3/printf gets you the man page for the printf(3) function in C (as opposed to the command-line utility, which is printf(1), and the default manpage for a simple man printf or x-man-page://printf).

Have you ever needed to know the address of your DHCP server? I don't know how useful this will be to people, but it was surprisingly tough for a team of three of us to figure out, so I figured it's worth a post. Surprisingly, the address doesn't show up in the system log, ifconfig, NetInfo, or anywhere else that we thought to look (and we looked in quite a few places)!

So here's the solution,. Go to the Terminal and run this command (replace en0 with en1 if you're on AirPort):

ipconfig getpacket en0 

According to the manual page for ipconfig, this command appears to be unique to Mac OS X, first introduced in the Public Beta! The command will display a bunch of useful info, including:

• server_identifier (ip): That's your DHCP server's IP address.
• yiaddr: Your machine's IP address.
• chaddr: Your machine's MAC address.
• domain_name_server: Your domain name server(s).

There's much more in the output. Keep in mind that if you have entered an IP address manually, then you'll get no output from this command. I have tested this in both 10.4.4 and 10.3.9, and it works fine in both.

I have been trying to fit large compressed archives onto standard CD and DVD media. I have seen a few examples here on how to do this, so by goofing around, I found another method. I used split -b to chop up the files to the desired size, and then cat to put them together again.

First, take the files you want to split and gzip them (I won't explain that part, as it is so easy). Then with the resulting .gz file, do the following:

split -b 5m "YourGzippedFile.gz" SegmentFileName

The -b option will let you specify the size (use k for Kilobytes and m for Megabytes) and the SegmentFileName is the name of the splits that will be created, with aa, ab, ac, etc. appended after SegmentFileName until the file is completely split up. So say you split a file that was 20MB into four 5MB chunks (just an example). To reassemble them:

cat MySegmentab >> MySegmentaa
cat MySegmentac >> MySegmentaa
cat MySegmentad >> MySegmentaa

This will take each segment, starting with the second, and join it to the first (head) of the segment. Your file will be back together. Then just add .gz to its name and then gunzip it.

I tried this with a regular .zip file from a PC, and Stuffit Expander uncompressed the pieces after I split and rejoined them fine, and I also did this to a 50MB AIFF that I gzipped first, then put it back together and it played fine.

This could be scriptable, but I haven't gotten that far yet. The downside to this method is that it is not automatic, so a script would be helpful. It is also not necessarily apparent as to what the files are, so you would need to make sure there is some description in the title that is obvious (Part 1 of x) or something like that. Comments and especially potential pitfalls to this method are encouraged.

The OS X 10.4.3 update brought a welcome bug fix for users of Apple's X11. Prior to that version, X11 windows would not raise when the program was selected in the Dock or with Command-Tab. This hint talked about some workarounds, none of which were very satisfying, so finally getting a patch came as some relief.

All was well until I installed X11 on my new iMac G5, which shipped with 10.4.3. I was dismayed to find that the old behavior had returned: X11 windows did not raise when the X11 app was activated. And, a later update to 10.4.4 later did not solve the problem. Was this a reintroduction of the old bug, or a new bug?

It turns out that Apple fixed the problem with the 10.4.3 updater, but forgot to fix it in the X11User.pkg they send out with Tiger installation disks. Since X11 is not installed by default, installing the non-updated version later leaves you with this minor but oh-so-frustrating bug. Since you cannot run the 10.4.3 updater on systems already at or beyond that OS version, you are seemingly stuck (kind of a fragile upgrade system if you ask me).