You may have noticed in a few rare instances your cursor in X11 becomes a transparent yellow outline. This is caused by a byte-order bug in Xquartz, in the instance your remote machine changes the cursor's appearance using an image rather than just a bitmap. (RedHat Linux systems do this to get a neat blue facet.)
Use the following if you have this problem. Do not apply this fix if you're running a PowerPC Mac.
Quit X11. Grab this file (2.7MB)) using Safari or command-line wget, then run this command:
sudo tar zxvf xfix.tar.gz -C /
Restart X11. The new binary simply adds a loop of ntohl() to the ARGB image in load_cursor(). A simple modification to quartz-cursor.c, found in X11-0.40.2 -> xc -> programs -> Xserver -> hw -> apple.
This is not my hint, but I'm reporting it here after seeing it posted elsewhere. Phillip Moore found a solution for occasional tcsh: no more processes and similar errors. Check his original post for details and the discussion.
One modifies /etc/launchd.conf by adding this line:
limit maxproc 512 2048
A restart is then required to activate the new settings. Or find some other way to restart launchd, which I didn't feel comfortable doing. I'd run into this problem sometimes after opening multiple Terminals and running a bunch of shell scripts.
[robg adds: As Phillip notes on his page, you only need to do this if you've run into the 100 process limit before; there's no other reason to do it. Visit his page for more details on the settings...]
Everyt ime I have come across hints about textutil, I have tried to use it for converting text files between different character encodings.
According to the documentation, textutil should be perfect for this. However, it has never worked. Until now. It seems like the -format and -convert flags must be specified, too. This example converts a macroman encoded file to latin-1:
I've found an easier way to check an md5 sum, or any other checksum for that matter. Just use this command:
md5 file_to_check | grep checksum_of_file
If there is an error, it will show the file name and the real checksum of the file. If there aren't any errors, then nothing will show up. You can do this for mutliple files by putting a semicolon (;) between the above code for each file.
I first learned about textutil in Mac OS X 10.4 in a tip here on macosxhints.com.
textutil is a rosetta stone for converting between different text file formats. For example, I recently wanted to change 36,000 .doc files into text files. So I needed to come up with a way of recursively converting all the files. The unix find command can be used to feed textutil. In Terminal, navigate to the appropriate directory (since this uses the current "." directory), and enter this command:
Read aloud: Find recursively in the current directory, by name, all the doc files. Execute the textutil 'convert to text' command with the found files. Bingo, done.
It has always annoyed me that a simple calculator would take several seconds to load on my current machine, and yet MacOS Classic's calculator is instantaneous even on my 33mhz 68k Mac. xcalc is also instantaneous, but requires x11 to load, which takes a while.
As I'm always running Terminal.app anyway, I thought a terminal calculator with a 'GUI' would be nice. After googling for it with no luck, I decided to write a shell script that mimics the behavior of a simple calculator. It loads instantly even on a iMac 233, although screen redraw can be a little sluggish on such hardware.
I'm not a developer in any way, so the code is probably the ugliest thing ever written, but it works for me. It handles only the basic 4 operations with 5 decimal cases. type 'q' to quit, the rest should be self explainable. Improvements are more than welcome -- for example, I couldn't map the clear key in the numeric pad, so I used 'c' for clear.
[robg adds: I mirrored the script here on hints. Remember to make it executable first (chmod a+x tcalc). I tested it, it seems to work well, and it is indeed speedy.]
After reinstalling my iBook from scratch this weekend, I started suffering (occasionally) from the old [Process completed] bug, as mentioned in this earlier hint.
Unfortunately, all the suggested fixes seem to be failing for me, including an upgrade to a newer zsh. As a user of zsh for the past ten years or so, I'm certainly not going to change shells, which made me think of this approach. It also gives me the joy of abusing both csh and dtterm at the same time. The principle is to use csh to bootstrap zsh, utilizing an obscure terminal type to signal csh to do so.
At the command prompt (if you can get one -- I was having this problem only occasionally), execute:
Then in Terminal Preferences, set "Execute the command (specify complete path)" to /bin/csh -l and "Declare terminal type ($TERM) as" to dtterm.
Of course, if you're unfortunate enough to have to still use dtterm emulation at any time, you'll have to substitute one of the other predefined terminal types.
The rule is to install any custom UNIX utilities in /usr/local, but unfortunately due to the way man is set up, the man pages for things installed in /usr/local may not be found.
The problem is that the man configuration file (/usr/share/misc/man.conf) defines a number of MANPATH_MAP directives. Here are some of them:
This means, for instance, that if you type man grep, man examines your PATH variable and finds that the grep executable is in /usr/bin. The MANPATH_MAP directive instructs it to look in the /usr/share/man directory to find the man page for grep. This overrides man's default behavior, which would be to look in the "nearby" directory /usr/man, which does not exist.
However, in the case of software installed in /usr/local, the man pages are more commonly (at least in my experience) installed in /usr/local/man, not /usr/local/share/man, so that MANPATH_MAP directive does the opposite of what we want.
If you keep all your /usr/local man pages in /usr/local/man rather than /usr/local/share/man, the simple solution is just to comment out that one MANPATH_MAP directory. You'll need to use sudo, since the /usr/share/misc/man.conf file is owned by root.
For a little while, now, I've used this Perl script to generate truly random passwords. I don't actually bother to remember them, of course -- that's what Keychain is for.
The program uses /dev/urandom as its source of randomness, which is the best source available on OS X and (essentially) what gets used to generate SSL sessions, FileVault keys, and the like. The program lets you specify the length of the password as well as the set of characters to choose from. If you use the -v flag, it'll tell you how large a keyspace you're drawing from.
You can easily use this program for one-off Web passwords. (Well, 'easily' if you're not put off by using the Terminal.) Just pipe the output to pbcopy, and then paste into the Web form; you never even have to see the password. This works in verbose mode, as well, since the messages are sent to STDERR. It might look as simple as this:
$ genpw | pbcopy
to generate a password and put it on the clipboard, if you're happy with the defaults. Or, it might look like this if you need a password for a Web site that restricts you to eight-letter (no digits or special characters) passwords, and if you want to get an idea of just how insecure that is:
$ genpw -vUln8
Generating a 8-character password
using /dev/urandom
and the following characters:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
This password is drawn from a keyspace of 46 bits.
----8<----cut-here----8<----
jtZJIjoP
---->8----cut-here---->8----
Full documentation and help is available through perldoc; just run perldoc genpw to have all your questions answered. This program is also BSD-licensed, so you can do almost anything you might like to do with it. Anybody who wants to wrap a GUI around it is more than welcome to do so.
Whenever you have a collection of data files that came from several different sources, there is the possibility that some of the files are duplicates of one another. For example, you might have sound loops that came with several different products (GarageBand, Soundtrack, etc) and there is some overlap between these. If you wanted to save disk space by clearing out the duplicates, the first thing you would need to do is identify which files are duplicates of each other. This is not always easy since the filenames are often unrelated.
(There is a previous hint that supplies a script for deleting duplicate sound loops, but that script relied upon lists of the duplicates having previously been prepared. There's also a hint on finding and removing iTunes duplicates via a Perl script.)
Today's hint supplies a script that will search for duplicate files in specified folders, and output a list of the files that are duplicates of each other. (i.e. it is something that will produce the lists that were used in the first previous hint.)
This is not my hint, but I'm reporting it here after seeing it posted elsewhere. Phillip Moore found a solution for occasional tcsh: no more processes and similar errors. Check his 
