I’ve been using zsh for a while as my preferred shell. I have a hacked-together zshrc file, and yet really wanted to use it across multiple systems. Some of those systems are running Mac OS X, others Solaris, and still others Linux. Executables are in a different locations and even have different switches across this range of systems, so my cobbled zshrc was not helping me.
As I was about to fall asleep last night, it finally hit me that fixing my zshrc would be a good thing to do. I jotted down some notes about an idea to reorganize it, and did something about it today.
Of course, since I’ve checked my zshrc and other dotfiles into a Mercurial repository, I could experiment without fear.
I created three top-level functions, with one “case” statement in each. Case statements may be evil in some fashion, but they are one of the things I like about shell scripting. These statements do allow the script to make choices based on the host, operating system, or shell that it was running in. (Yeah, it’s a zshrc, but I sometimes do stupid things — like sourcing it in bash on the one Linux system that won’t let me switch to zsh. Site5, I’m looking at you.)
I separated all the important sections of my zshrc into their own individual function calls. Each of those function calls was placed into one of the applicable case statements.
The case statement functions figure out the conditions the zshrc is running in, and then run the other functions to set up my environment.
The changes tested well from first try across the various platforms and hosts I log in to. I did have a minor problem with the `hostname` command, because Solaris doesn’t have a “-s” flag for it. Eventually, I solved that — and the odd “uname: error in setting name: Not owner” error I got, even though I wasn’t directly running `uname` there — by replacing `hostname` with `uname`.
Thankfully, it works for me, and it should be a little easier to manage changes in the future.
I recently took a trip to Seattle, and reminded myself of a useful practice I’d developed a while ago. When I’m traveling, I collect import URLs for that trip in my browser — URLs for my organization’s travel booking/information system, airlines, hotels, maps, conference information, etc. — and put them in Safari’s Bookmarks Bar.
It’s pretty easy to collect them:

The resulting bookmarks can be rearranged, if necessary, in Safari’s bookmarks editor. (It’s the “open book” icon in the Bookmarks Bar.)
The entire group of pages can be opened all at once by clicking-and-holding on the folder in the Bookmarks Bar. When the menu drops down for the folder, choose the last command: “Open in Tabs.” This opens all of the sites bookmarked in the folder in separate tabs in the Safari window. I find that it’s useful to have them all open while I’m traveling to my destination, since that way I can see them even if I can’t get an Internet connection — free Wi-Fi is not always available.
When I’m done with the trip, I can delete the entire folder or just some of the bookmarks it contains. To delete the folder quickly, right-click on its name in the Bookmarks Bar and choose “Delete” from the contextual menu.
The Xcode 3.1 Developer Tools install both the standard GNU compiler, gcc, and the LLVM compiler, llvm-gcc. I thought I’d try my hand at compiling something with LLVM, so naturally I decided to update my instructions for compiling Rsync 3 as a Universal Binary for Leopard. Let’s try Rsync 3.0.3!
The following set of instructions, of course, requires that you have already installed the Xcode 3.1, available as a download from Apple. To choose LLVM as your C compiler temporarily for this compile, specify the CC=“/Developer/usr/bin/llvm-gcc” variable (as explained in the LLVM FAQ).
$ cd /tmp
$ curl -O curl -O http://rsync.samba.org/ftp/rsync/rsync-3.0.3.tar.gz
$ tar -xzvf rsync-3.0.3.tar.gz
$ rm rsync-3.0.3.tar.gz
$ curl -O http://rsync.samba.org/ftp/rsync/rsync-patches-3.0.3.tar.gz
$ tar -xzvf rsync-patches-3.0.3.tar.gz
$ rm rsync-patches-3.0.3.tar.gz
$ cd rsync-3.0.3
$ patch -p1 <patches/fileflags.diff
$ patch -p1 <patches/crtimes.diff
$ ./prepare-source
$ env CFLAGS="-O -g -isysroot /Developer/SDKs/MacOSX10.5.sdk -arch i386 \
-arch ppc7400 -arch ppc970 -arch ppc64 -arch x86_64" LDFLAGS="-arch i386 \
-arch ppc7400 -arch ppc970 -arch ppc64 -arch x86_64" \
CC="/Developer/usr/bin/llvm-gcc" \
./configure --prefix=/usr/local --disable-dependency-tracking
$ make
$ ./rsync --version
rsync version 3.0.3 protocol version 30
Copyright (C) 1996-2008 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
64-bit files, 32-bit inums, 64-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
append, ACLs, xattrs, no iconv, symtimes, file-flags
rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.
$ file ./rsync
./rsync: Mach-O universal binary with 5 architectures
./rsync (for architecture i386): Mach-O executable i386
./rsync (for architecture ppc7400): Mach-O executable ppc
./rsync (for architecture ppc970): Mach-O executable ppc
./rsync (for architecture ppc64): Mach-O 64-bit executable ppc64
./rsync (for architecture x86_64): Mach-O 64-bit executable x86_64
$ lipo -info ./rsync
Architectures in the fat file: ./rsync are: i386 ppc7400 ppc970 ppc64 x86_64
$ sudo make install
Warning: I have not tested Rsync 3 compiled with LLVM to ensure that it operates at all or is compatible with Rsync compiled by GCC. I haven’t compared the compilation speed against GCC’s performance, determined whether the files are larger/smaller, or have produced a more optimized binary. You use the software compiled with these instructions at your own risk.
Most of the original instructions were helpfully documented by Mike Bombich. My contributions are simply:
Since the Bit.ly URL-shortening service is all the rage lately, and I hadn’t seen anyone create a Mac OS X Service for it yet, I decided to try my hand at it.
Here’s the result. The core is a relatively simple Python script and requires Mac OS X 10.5 (or Python 2.5 if you have an earlier version of Mac OS X). The Service was wrapped up with ThisService by Peter Hosey. It’s my first attempt at creating a Mac OS X Service — with or without ThisService — and I hope it works for you. However, it is provided “as-is” with no warranty.
That said, if you have comments or suggestions, please feel free to contact me.
Also, I’m not counting this as an endorsement of Bit.ly; I just looked at info on their site and thought I could probably script it and, as you can see, I did.
To install the Service:
To use it:
Of special note, however, is that if you shorten URLs with Bit.ly this way rather than through your browser, you probably won’t see them show up in your history (the most recent 15 URLs you’ve shortened). The script just shortens URLs for you and does so outside of your browser, so whatever cookies or other tracking Bit.ly is doing to generate your history, it doesn’t appear to carry over when using this simple little Service.
| Attachment | Size |
|---|---|
| ShortenUrlWithBitly.zip | 34.17 KB |
It’s taken about a decade but I finally read the man page for “less.” Here are some important keyboard commands for navigating through files with it that I wanted to note for my own future use. If someone else gets a benefit from this, great, but it’s already helping me jump through man pages with more ease. (And it gave me an opportunity to write a post with a really ambiguous title.)
| Key | Function |
|---|---|
| f | Move forward one screen |
| b | Move backward one screen |
| j | Move forward one line |
| y | Move backward one line |
| = | Show the number of lines and your progress through the file |
| < | Move to the beginning of the file |
| > | Move to the end of the file |
| % | Scroll to the position in the file represented by the number before the percent sign |
These commands had eluded me for a long time, even though it would have been great to know them. After all, less is the default pager in Mac OS X. Thanks to the wonders of air travel, I had some time to read some off-line documentation.
Of course, I’ve long used “/” followed by some text to search through man pages, and that’s worth knowing if you don’t already. One useful trick I picked up was the search “/^EXAM” (props to Adam for mentioning the caret and making my recipe one character longer, but more specific) to search for the examples section.
In trying to determine the age of the command file on a Radmind client — in this case, a Mac OS X 10.5 Leopard system — I learned that its modification date is the same as on the server. This is true on multiple clients I examined, so I believe it to be both consistent and intentional. It also makes sense.
What timestamp, then, can you use to determine how old your command file is, or when your client last updated?
Let’s look into this. For example, here is the command file on a client:
[RadmindClientA]$ ls -ul /private/var/radmind/client | grep command.K
-rw-r--r-- 1 root wheel 667 Jun 3 05:30 command.K
[RadmindClientA]$ ls -cl /private/var/radmind/client | grep command.K
-rw-r--r-- 1 root wheel 667 May 29 10:28 command.K
[RadmindClientA]$ ls -l /private/var/radmind/client | grep command.K
-rw-r--r-- 1 root wheel 667 May 29 10:21 command.K
And the same file examined on the server:
[RadmindServer]$ ls -ul /private/var/radmind/command | grep selected-client-command.K
-rw-r----- 1 root wheel 667 Jun 3 05:27 selected-client-command.K
[RadmindServer]$ ls -cl /private/var/radmind/command | grep selected-client-command.K
-rw-r----- 1 root wheel 667 May 29 10:21 selected-client-command.K
[RadmindServer]$ ls -l /private/var/radmind/command | grep selected-client-command.K
-rw-r----- 1 root wheel 667 May 29 10:21 selected-client-command.K
The status change time (ls -cl) is a little bit harder to understand. I’ve seen it minutes apart from the modification time on a client, but it is the same as the modification time when viewed on the server.
The access time (ls -ul) of the command file on the client, however, simply corresponds to when ktcheck last ran.
For good measure, another client:
[RadmindClientB]$ ls -ul /private/var/radmind/client/ | grep command.K
-rw-r--r-- 1 root wheel 1188 Jun 5 05:08 command.K
[RadmindClientB]$ ls -cl /private/var/radmind/client/ | grep command.K
-rw-r--r-- 1 root wheel 1188 Jun 3 14:13 command.K
[RadmindClientB]$ ls -l /private/var/radmind/client/ | grep command.K
-rw-r--r-- 1 root wheel 1188 Jun 3 14:09 command.K
And its command file on the server:
[RadmindServer]$ ls -ul /private/var/radmind/command | grep another-selected-client-command.K
-rw-r--r-- 1 root wheel 1188 Jun 4 05:13 another-selected-client-command.K
[RadmindServer]$ ls -cl /private/var/radmind/command | grep another-selected-client-command.K
-rw-r--r-- 1 root wheel 1188 Jun 3 14:09 another-selected-client-command.K
[RadmindServer]$ ls -l /private/var/radmind/command | grep another-selected-client-command.K
-rw-r--r-- 1 root wheel 1188 Jun 3 14:09 another-selected-client-command.K
I looked into this because I was wondering why ktcheck -C (to “clean” the /private/var/radmind/client directory) wasn’t having the effect I expected. I thought it cleared out the client directory and started with fresh files, which would all have new timestamps because they were new to the client. When I didn’t get the new timestamps I anticipated, I worked through what I saw until I settled on this explanation.
The result? The main means you have of determining whether the command file has been updated is its access time. The access timestamp corresponds with the date and time of the last ktcheck action. This appears to be the case no matter which flags I’ve used with ktcheck — even with ktcheck -n (where “no files are modified”).
The modification time, for all intents and purposes, only indicates when the file was last changed on the server. Testing this out — with command files that have been overwritten with the exact same contents (using cat), as well as command files deleted on the client before ktcheck — I have reached the conclusion that the modification time changes only when the file contents do.
So, I don’t have solid explanations for all of this. But, I’m now armed with the knowledge that the access timestamp is the most important when you’re looking for the age — or at least the last refresh time — of a Radmind client’s command file.
In Leopard, launchd has some options that can tailor your now-working LaunchAgents for specific circumstances. For example, if you want your LaunchAgent to run only when a user has logged in at the Aqua console — rather than SSH or other login sessions — you can use the “LimitLoadToSessionType” key:
<key>LimitLoadToSessionType</key>
<string>Aqua</string>
Note that to find events that have been limited in this way, you must use launchctl’s “-S” flag to specify the session type. Otherwise, launchctl won’t find jobs that are specified for a different kind of session than the current one, as per Levi Brown’s post.
I also found the “LimitLoadToHosts” and “LimitLoadFromHosts” keys when looking this topic up in the launchd.plist man page.
Thanks to James Bucanek for mentioning this on the launchd-dev list.
Under normal circumstances, the latest Radmind tools that communicate with the server report client status updates in the Radmind server’s system log. These standard messages can include ones like:
May 8 03:14:56 RadmindServerHost radmind[7890]: report radmind-client.example.com 192.168.7.42 - - ktcheck No updates needed
May 15 03:15:25 RadmindServerHost radmind[24531]: report radmind-client.example.com 192.168.7.42 - - ktcheck Updates retrieved
May 15 03:21:48 RadmindServerHost radmind[24534]: report radmind-client.example.com 192.168.7.42 - - lapply Changes applied successfully
May 15 03:31:07 RadmindServerHost radmind[24356]: report radmind-client.example.com 192.168.7.42 CertificateCN - lapply Error, changes made
The Radmind repo, or “report,” tool provides the ability to send arbitrary messages to the Radmind server process. But how are these messages formatted and sent?
$ repo -e "Debug" -h radmindserverhost.example.com -w2 "Test message"
… results in the system log message:
May 15 03:31:56 RadmindServerHost radmind[25236]: report radmind-client.example.com 192.168.7.42 CertificateCN - Debug Test message
Here, we can see that an entry created with repo looks like the standard Radmind log messages above. The client hostname and IP address are reported after the “report” text. The CertificateCN for the client — if the highest authorization level is specified (with the -w2 flag) — is also listed; if not, a dash takes its place. I haven’t seen a case where the second dash is substituted, however.
Finally, where the Radmind command/tool used would normally be, the “event” specified by repo will printed. After that, the message text appears.
The value proposition is that if you’re using Radmind, the repo command can help you send arbitrary messages to the server for logging. As bonus, if you’ve taken the time and effort to build the certificate infrastructure for Radmind, you can send these messages securely between the clients and the server cloaked in SSL.
If you’re using multiple servers, you may want to combine their logs in one location so that you can get all of the clients’ reports in one location. You may also want or need to retain these reports for more time. In either case, determine what policies you should apply to the syslog or Apple System Logger (ASL, for Mac OS X) configuration for your server systems.
Whether or not you use repo, it’s good to know that the tools do some logging. The logging can be followed to try to determine the status of your clients, or whether they are failing their updates.
Unfortunately, the most common client failures I have seen tend to involve the lapply tool, and the default level of detail I’ve seen reported back to the server does not provide an indication of what problem has been encountered. You see only that there was an error. Still, even though you may not get enough detail to remotely resolve the problem, it’s something for you to go by find problems in the first place.
I’m constantly astounded by the breadth of features available in the Python Standard Library. Although the functions I find there are not always easy to grasp, it is almost always worth searching around a bit for a function or method in the standard library before I write my own code to do something someone else has probably had to do before.
Take the “locale” module. It lets you format certain kinds of data based on your locale and its customs. Numbers (including currency) happen to be one of its specialties. Since I had a need to output long numbers whose digits were grouped with commas — which makes them easier to read — and locale.format() does just that. Even better, it’s internationalized and formats them for your system’s own locale.
>>> import locale
>>> a = {'size': 123456789, 'unit': 'bytes'}
>>> print(locale.format("%(size).2f", a, 1))
123456789.00
>>> locale.setlocale(locale.LC_ALL, '') # Set the locale for your system
'en_US.UTF-8'
>>> print(locale.format("%(size).2f", a, 1))
123,456,789.00
In trying to use it in the bundled Python 2.5.1 on Mac OS X Leopard, I noticed that the default for scripts and the interpreter doesn’t format numbers as I expected for my locale. I found that I needed to set a locale to get the expected formatting. To do this, I run locale.setlocale(), as above. I’m not sure if this is required for other Python installations, but it’s worth mentioning.
One difficulty I created for myself was when I tried mixing more into my format string. For example, locale.format() would fail to reformat a number when I added in the string for the unit from my original dictionary:
>>> print(locale.format("%(size).2f %(unit)s", a, 1))
123456789.00 bytes
In retrospect, this makes total sense, but it took Mark looking over my code to discover my error.
In Python, there is a built-in string method, “startswith,” that lets you determine whether a line starts with a character. I’ve used it before because I tend to want to use the features of the standard library, despite having awesome features like slicing at my disposal. What I didn’t realize immediately, though, was how to compare the string against two or more sets of characters. All I knew is that entering a list as the prefix — instead of the more common single string — didn’t work.
Luckily, my question was answered right away in the string method documentation. I found that to perform these comparisons together, you must supply the “startswith” string method with a tuple. It works the same for the “endswith” method. However, this does require Python 2.5.
>>> starts_with = ('f', 'a')
>>> def does_startwith(selected_text):
... if selected_text.startswith(starts_with):
... print True
...
>>> does_startwith('z is a letter')
>>> does_startwith('f is a letter')
True
>>> does_startwith('b is a letter')
>>> does_startwith('a is a letter')
True
This has some application to a larger question I had, so I wanted to note it.