At one time, OS X didn't consult the hosts file before doing a DNS lookup. In 10.3 and 10.4, it does. You can check the name resolution order of your Mac using Terminal; enter the following:
Look for the following in the output:
LookupOrder: Cache FF DNS NI DS
_config_name: Host Configuration
The FF (flat file) refers to your hosts file (/etc/hosts), and Tiger does check its contents before going to DNS and Netinfo. Just a little FYI for those who may not have realized that 10.4 fixed things.
Make sure you include http:// in the URL when fetching a remote webpage. If you don't, webarchiver attempts to locate a local file. Webarchiver is only compatible with OS X 10.4, and is a universal binary.
[robg adds: This worked as described in my testing.]
So you have Boot Camp and a big disk to use, but then you are bound to the NTFS format instead of FAT. But Mac OS X 10.4 can only read, not write, to these kind of formatted volumes. Follow these steps and you will be able to write to them as well:
If you choose to compile yourself, install Xcode 2.4.1, and especially the SDK package within it. Also, compile the latest release of pkgconfig.
Download MacFuse. Compile it yourself, or easier of course, is to download the binary .dmg file.
Download ntfs-3g and compile it -- there's also a premade binary .dmg if you prefer.
In Disk Utility, check out the device identifier (disk0s2 or something) of the NTFS volume, and unmount it.
In Terminal, type mkdir /Volumes/your_ntfs_volume, where your_ntfs_volume is the name of your NTFS volume.
Still in Terminal, type ntfs-3g /dev/disk0s2 /Volumes/your_ntfs_volume -o ping_diskarb,volname="your_ntfs_volume".
Normally your volume should be mounted. If not, type disktool -r and killall finder. To unmount, use sudo umount /dev/disk0s2. Use AppleScript if you want to facilitate mounting and unmounting.
[robg adds: I haven't tested this one, and would caution that if you plan to test it, you have a good backup before you begin.]
opendiff is a command line app for merging text files. It is installed when you install the Xcode Developer Tools on Mac OS X, and calls FileMerge.app. By default, opendiff does not wait for FileMerge.app to finish before exiting. This makes it hard to integrate opendiff with other Unix tools. After some searching, I found a solution.
In particular, opendiff will wait if the output is piped somewhere. I handle this by making a new shell script I call opendiff-w with the following code in it:
Then you can use opendiff-w just as you would opendiff, but it will wait until you quit FileMerge.app before continuing. It would be better still if FileMerge had a way to know when the diff was done without having to actually quit the app. Any suggestions?
I've often searched for a replacement for the standard icons that come with Apache. The default icons date back to Mosaic for X, and have been included in the NCSA httpd and Apache server distributions. These continue to be distributed with even the latest versions of Apache. I haven't found any publicly available replacements for these icons, so I decided to build my own.
I didn't reinvent the world here, I just modernized the standard set. The task of creating a whole new representational logic was too great a task for my purposes. Furthermore, the prevalence of these icons makes them easily understood. All icons maintain their original sizes, so they can be used as a drop in replacement.
On OS X, the standard installation location is /usr/share/httpd/icons. This directory is referenced by a global directive in the httpd.conf file. This includes an alias for /icons/ that is resolved for every domain being served. On OS X, this directory is owned by the system (root) with the group ownership belonging to wheel. It is best to follow the same permission model when replacing these files.
I received an iPod for Christmas -- I've admittedly been resisting this convenient technology because I am not satisfied with the audio quality of MP3s, even at the higher bitrates. I've revisited this issue since receiving my gift, however, and I'm mightily impressed with AAC at 256kbps: I've done listening tests of AAC against uncompressed audio with strings, voice, symphonic, and amplified music, and am sold on 256kbps AAC. It requires nice components for me to discern the difference from the original, and I sure can't on the little iPod.
I began converting my CD collection to AAC, but quickly became dissatisfied with Apple's tools to do this, either through iTunes or via Max. Neither does track normalization for a large collection, and Max's rips often produce white noise output for me.
Having used and trusted cdparanoia and cdrdao to obtain high quality rips for years now, I wrote a perl script based on these tools to rip a CD, grab the CDDB information, normalize the tracks, convert everything to a specified codec (AAC, ALAC, flac, mp3, etc.), and add the CDDB information to the resulting files. The script also does the correct UTF-8 conversion for non-English scripts. (I have an extensive Arabic collection from Beirut -- it's pretty neat to have the correct Arabic script appear in iTunes). To use this script, you'll have to download and build your own executables of the following tools (you must know how to type ./configure; make; make install):
I've written this script for my own needs, but it's easy to modify to incorporate other formats. To use, save the text to a file named cd2codec, do chmod a+x cd2codec, get/build the required tools, and type cd2codec --help for usage instructions. If you wish to add foreign language scripts to your mp4tags, then also grab a copy of my transliterate perl script, too, which provides the octal UTF-8 transliteration of Arabic and Greek. Cyrillic, Hebrew, and others are possible, too, but not implemented.
I wrote this perl script which transliterates ASCII into UTF-8 colloquial and classical Arabic, Greek, and (at some point in the future) Cyrillic, Hebrew, and other scripts. Input: ASCII. Output: UTF-8 and octal representation of UTF-8.
I've used this to input foreign language titles into my iTunes world music collection. Once you've generated the octal UTF-8, this can be done by hand:
The iTunes song title of the AAC file 'ajmal mnw9aat al-jaaz 01.m4a will appear as 9rabiyuN 'anaa (عرَبِيٌ أَنَا). Or enter these codes into a cdrdao TOC file, and use my cd2codec script with the command cd2codec --utf8 to accomplish this automatically. I've written this script for my own needs, but it's easy to modify to incorporate other formats. To use, save the text to the file transliterate, do chmod a+x transliterate, get/build the required tools, and type transliterate --help for usage instructions.
Arabic transliteration is simply a colloquial Arabic front-end for Otakar Smrz's excellent ArabTeX perl script; you'll need to download and install Encode and Encode::Arabic from CPAN. I've also implemented a simple Greek transliteration engine (no accents or breathings) that runs without any additions. I've left placeholders for Cyrillic and Hebrew extensions, but these are not implemented.
While messing around trying to share my iTunes library between two user accounts on the same iMac, I accidentally introduced a syntax error into my /etc/sudoers file. The big problem here is you need to invoke sudo to edit the sudoers file; I use pico, but visudo is recommended on this site.
So, to recover from this, I had to enable my root account using NetInfo in Applications » Utilities. Log in as root and edit /etc/sudoers, then once it's fixed and working, disable the root account again.
[robg adds: There's a good reason visudo is the recommended way to edit your sudoers file, and this hint is a perfect demonstration of why: because visudo includes a basic check for syntax errors, as explained in the man page:
visudo edits the sudoers file in a safe fashion, analogous to vipw(8). visudo locks the sudoers file against multiple simultaneous edits, provides basic sanity checks, and checks for parse errors.
So you really should use visudo if you're going to edit the sudoers file. If you don't, however, and introduce errors, you'll need this hint to fix the problems.]
This may seem like an obvious hint, but I have been caught out by it a couple of times. When installing software using Fink or DarwinPorts (aka MacPorts), make sure you have the latest version of Apple's Developer Tools (Xcode) installed (free registration required to download).
Developer Tools is ignored by Software Update -- and using an old version tends to cause software to fail to compile. I keep getting caught out by these failures, and after making sure I have the latest version of Fink, doing fresh installs, permission repairs, etc., I finally remember to check the developer site for a new version.
I noticed on my MacBook (OS X 10.4.8) that the underlying UNIX based system (POSIX) was not going to update correctly for the Daylight Savings Time (DST) change in my time zone (America/Vancouver). To determine if your time zone has an issue, run this command in Terminal:
foo$ zdump -v /etc/localtime | grep 2007
If you see this in the output, then your DST will not start (or end) on the correct day:
/etc/localtime Sun Apr 1 09:59:59 2007 UTC = Sun Apr 1 01:59:59 2007 PST isdst=0
/etc/localtime Sun Apr 1 10:00:00 2007 UTC = Sun Apr 1 03:00:00 2007 PDT isdst=1
/etc/localtime Sun Oct 28 08:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 PDT isdst=1
/etc/localtime Sun Oct 28 09:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 PST isdst=0
Notice that those dates do not correspond to the second Sunday in March nor the first Sunday in November. Read on for a solution to this problem...
[robg adds: For those who aren't aware, DST will start earlier this year in the United States and most of Canada. From the Daylight Savings Time entry at Wikipedia (note the start and end dates for 2007):
DST commonly begins in the northern hemisphere on the last Sunday in March or the first Sunday in April and ends on the last Sunday in October. However, due to the Energy Policy Act of 2005, beginning in 2007, the United States will begin observing DST from the second Sunday in March until the first Sunday in November.
I looked at most of the US timezone files (Pacific, Central, etc.), and they all seem to be correct -- so many of you may not have to implement the solution explained in the remainder of this hint.]