Mac OS X Leopard and Snow Leopard come with a paltry set of solid colors for desktop backgrounds. This is easily remedied with the ImageMagick package (available for install through both MacPorts and Fink), and a quick Terminal command.
The script below generates all the background images for web-safe colors that should then be immediately available for use in the Solid Colors section of the Desktop tab of the Desktop and Screen Saver System Preferences panel.
cd /Library/Desktop\ Pictures/Solid\ Colors; for r in 00 33 66 99 cc ff; do for g in 00 33 66 99 cc ff; do for b in 00 33 66 99 cc ff; do echo Creating image for color $r$g$b; convert -background "#$r$g$b" -page 256x256 text:- "Background $r$g$b.jpg" < /dev/null; done; done; done
You can copy and paste the script into Terminal, but you’ll need to be a system administrator for it to succeed, because it writes the images into /Library/Desktop Pictures/Solid Colors.
[robg adds: I tested this on a 10.5 machine, and it works as described. If you just have a few solid colors you want to use, you can create them yourself, as we covered in this hint. In addition, if you'd like to make it possible to use any color as your desktop background, you can create a 128x128 transparent PNG, and then use a color picker to set the color of the desktop to anything you like -- see this hint for more details.]
All the cool kids are using fish (bash is so 90's!), so why can't I? Because it won't install on my copy of Snow Leopard, dang it. I spent the greater part of this weekend trying to figure out why fish didn't like me. Read this so you won't have to endure my pain.
Using MacPorts, typing port install fish wouldn't result in a working installation. The install kept asking for iconv, gettext, or whatnot. 64-bit/32-bit Unix apps don't play well together in Snow Leopard, and because I upgraded from Leopard, I needed to reinstall MacPorts to deal with it. Long and painful, indeed.
The free program cmd-key-happy allows you to swap the Command and Alt/Option keys in any application, but in particular, in Terminal.app.
This can be extremely handy when ssh'ing into other UN*X boxes and running emacs -nw. It also allows you to have the traditional readline navigation work properly when using Bash (i.e., alt-backspace, alt-f, alt-b, etc). See this blog post for more details.
[robg adds: Installation help is available in the INSTALL file in the github repository. I haven't tested this one.]
For an upcoming project involving virtualization applications, I wanted an easy way to record the CPU usage for a given program over time.
I'm aware of the Instruments program included in the Xcode Developer Tools, but I was looking for something simple, that I could run without a lot of overhead, and that would just record data for further analysis in Excel.
After a bit of digging with Google, I didn't find anything that quite worked (a friend tells me that mrtg and Cacti should handle this; I haven't tried them yet), so I created a relatively simple bash script to get the job done - special thanks to Keith Bradnam for assistance in making it more interactive.
The program reports on a chosen program (process ID, actually) at a specified interval, then saves a few items (timestamp, process ID, CPU usage, and command name) to a text file, in this format:
The program does not create pretty graphs, or do any sort of analysis -- that part is up to you! However, with the data, you can do some interesting things. For instance, the graph above (click it for a much larger version) shows Firefox's CPU usage while browsing and playing a few Flash games on my MacBook Pro for ten minutes or so.
While it is well known that Mac OS X contains open source code, how to access and download that source code is perhaps less well known. Apple publishes all its open source code on their Apple Open Source site. However, this site makes you download each program individually, without an obvious option to download an entire OS X release at once (i.e., all public sources for 10.6.1).
So I wrote the following bash script to automate the download procedure. It downloads the individual tarballs for each program, expands them locally, and then rolls everything up into one big tarball for local storage. Some caveats are that this script does not build the code, and that you are bound by a variety of licenses which are not included here (because no Apple code is included here).
#!/usr/bin/env bash
# --- applesource.bash --- downloads source code for an entire Apple release
# Take input from command-line (use "10.5.8", "10.6.1", etc.)
version="mac-os-x-`echo $* | tr -d "."`"
# URL:
homepage="http://www.opensource.apple.com"
URL="${homepage}/release/${version}/"
# Announce beginning, and prepare a directory for the untarred sources
echo "Preparing to download..."
sources="./${version}-sources"
mkdir -p ${sources}
# Process the webpage for the locations of the tarballs themselves
curl --silent ${URL} | sed -n 's/<a href="\(.*.tar.gz\)">/\1/p' | \
while read line; do
# Find and announce the name of the next tarball to be downloaded
tarball=".${line}"
echo -e "\nDownloading `basename ${tarball}`..."
# Download the tarball and keep Apple's original directory structure intact
curl --create-dirs --output ${tarball} "${homepage}${line}"
# Untar into the "sources" directory (see line 13)
tar xfz "${tarball}" -C ${sources}
done
# Compress all sourcefiles into a single tarball for posterity
echo "Creating ${version}.tar.gz from all sources..."
tar cfvz "${version}.tar.gz" ${sources}
# Explicitly show that everything finished.
echo "Done."
# I like for my Mac to talk to me, although sometimes this can be creepy.
say "The source of ${version} is now ready."
Save the above somewhere on your path, make it executable (chmod a+x scriptname), and then run it with the version number you'd like to download: getsource 10.6.1, for instance. I am a bit shy about releasing my scripts, so please be gentle!
[robg adds: I tested this and it worked as described.]
I am an old timer and use top (instead of Activity Monitor) to keep an eye on my system.
I just notice that in Snow Leopard when you horizontally resize the Terminal (or xterm) window, top displays more information about the running processes -- new columns are added as the window grows wider. Use man top to get an explanation of what those extra columns display.
Another nice change is that the Process ID (PID) is now suffixed with - to indicate a 32-bit process, and a * to indicate a PowerPC process.
This is probably evident for Unix wizards, but I spent a whole morning figuring this out so I thought some of you might find it useful too.
I have a client app which does not permit specifying a non-standard destination port. In this example, it is an LDAP client which will only contact a host on the local network on the standard port 389. The LDAP server it is trying to contact is in the local network at 193.168.4.253, but listening on the non-standard port 712. So, I had to set up a port translation for outgoing connections. The code to achieve this is as follows (must be run with sudo privileges, or as root in a launchd startup daemon to make it persistent):
sysctl -w net.inet.ip.forwarding=1
ipfw add 01000 divert natd tcp from me to 192.168.4.253 389 via en0
ipfw add 01000 divert natd tcp from 192.168.4.253 712 to me via en0
cat > natd.conf << end
interface en0
reverse
same_ports
redirect_port tcp 192.168.4.253:712 192.168.4.253:389
redirect_port tcp 192.168.4.253:389 192.168.4.253:712
end
natd -f natd.conf
Specifically, what this does is enable ipfw forwarding, then set up that ipfw should pass all traffic to host 192.168.4.253 on port 389, and from host 192.168.4.253 port 712 to the natd daemon. natd gets launched as a daemon and is told to rewrite the outgoing connection to the host's port 389 to the "real" port 712. All returning packets from the host's port 712 are then translated back to the original port 389 expected by the client application.
The following two functions (just add to your .bash_profile or .profile file) will make life easier when encrypting and decrypting files with openssl in Terminal:
function encrypt {
if [ "$1" = "" ]; then
echo "Usage: encrypt filename"
elif [ -d "$1" ]; then
echo ""$1" is a directory"
elif [ -L "$1" ]; then
echo ""$1" is a symbolic link"
elif ! [ -r "$1" ]; then
echo ""$1" is not readable"
else
/usr/bin/openssl aes-256-cbc -salt -in "$1" -out "$1".aes
if [ $? -eq 0 ] ; then
echo "encryted file: "$1".aes"
fi
fi
}
function decrypt {
if [ "$1" = "" ] || [ "${1##*.}" != aes ]; then
echo "Usage: decrypt filename.aes"
else
/usr/bin/openssl aes-256-cbc -d -salt -in "$1" -out "${1%.aes}" 2>/dev/null
if [ $? -eq 0 ] ; then
echo "decryted file: ${1%.aes}"
else
/bin/rm "${1%.aes}"
echo -e "bad decrypt, possible incorrect password \n(${1%.aes} deleted)"
fi
fi
}
For rsync users, the newest version of rsync (3.0.6 as of this moment) seems to be able to handle Mac extended attributes and resource forks correctly. Unfortunately, it doesn't seem to ship with Snow Leopard, but it can be downloaded and installed fairly easily.
After downloading from the above-linked site, just follow the instructions in the INSTALL text file, and remember that the make install command needs to be run with administrator privileges (sudo). Further, you may need to adjust your PATH and MANPATH settings, so that /usr/local/bin and /usr/local/share/man (the default install locations) appear earlier in the list than do /usr/bin, the home of the stock rsync.
Your current rsync scripts may need some tweaking, too. For example, the -E flag no longer refers to extended attributes (it now tells rsync to preserve executability); -X is used for extended attributes. Also, -X is not included in the standard -a (archive) flag, and should be added explicitly.
[robg adds: The version of rsync in both Leopard and Snow Leopard is quite old -- 2.6.9, which shipped in November of 2006. You can also install the newest rsync via either MacPorts or Fink.]
Snow Leopard introduces a new feature that has been used on most of the system files: HFS+ compression. This compression is rather different than most other file compression options available in the sense that it is completely transparent; there isn't even a way to tell that the files are compressed using Snow Leopard's included command line tools (in fact, contrary to what some posts on this site have suggested, command line utilities like strings will see the same file regardless if it is compressed or not).
In order to even determine if a file is compressed using HFS+ compression or not, a tool like hfsdebug is needed.