• A list of links to programming resources
  tags: programming +

So I was having this weird problem where the results of Find command were coming back with a double slash in the file path.

After thinking I’d solved it and starting to write out the solution, I realized the issue was because my search target was a symbolic link. I then found Find’s switch for dealing with this problem. Doubtlessly someone else is or will come across this same issue, so I’ll explain what was happening anyway.

This all came up because I needed to grab a set of files that resided in my /tmp directory. On Mac OS X, tmp is actually a symbolic link (a unixy kind of alias) which points to /private/tmp.

Here are a few iterations of this command and a description of their results:

find /tmp -name 'Web*' -print

Returns nothing because find is searching /tmp as a file instead of following the link to the target directory.

find /tmp/ -name 'Web*' -print

This returns the files I was looking for, but their paths contained double slashes (ie. /tmp//Webkit...). The double-slashes were strange, and I suspected (wrongly, keep reading) that they might be causing problems with later commands.

find /tmp/* -name 'Web*' -print

This works, and returned correct file paths, but it probably uses shell expansion which seems silly on top of Find’s own abilities.

Reading the man page again, after the symbolic link realization, I finally saw the -H flag:

The -H option causes the file information and file type (see stat(2)) returned for each symbolic link specified on the command line to be those of the file referenced by the link, not the link itself. If the referenced file does not exist, the file information and type will be for the link itself. File information of all symbolic links not on the command line is that of the link itself.

Well that took a stupid amount of time to discover. Using -H, the command works perfectly with the simple /tmp target:

find -H /tmp -name 'Web*' -print

Same results as the /tmp/* line, but a much cleaner command.

A funny, or sad, footnote of this story is that my original problem had nothing to do with the double-slashed paths. I didn’t realize the files were owned by root and that was causing my command to fail.

Bruce IM’d with a quote I hadn’t seen in years:

>”Hip is transitory. Smart endures. Hip is defined by others. Smart is defined by intelligence. Hip is only for the moment. Smart is timeless. Hip is driven by trends. Smart is driven by performance. Hip is perpetually looking over your shoulder. Smart is making your own decisions. Hip is mango-chestnut gelati. Smart is chocolate ice cream. Hip is often difficult to define. Smart is always logically defensible. Hip is flash. Smart is substance. Hip is something that looks cool. Smart is something that works. Hip talks the talk. Smart walks the walk. Hip gets you a $300 a week cocaine habit. Smart gets you a big raise and the corner office.” 

He remembers it from a xeroxed handout in one of Brad Durham’s classes we both had at Art Center sometime in the very early 90s.

Amazingly, that only appears to be in Google once, on a seemingly abandoned Tripod page. Nothing in the Usenet archives and most non-Google search engines couldn’t even find the one tripod page.

Anyone remember where this is from or who wrote it?

*update:* also posted to Google Answers

Setting up icon placement and window sizes on a disk image isn’t as easy as it should be. Here’s part of my solution for automating a designed disk image with AppleScript.

Fixing Window Size

According to this thread on Apple’s Installer-dev list, window size isn’t written until there is some user interaction, specifically clicking either the green zoom button or the little resizing thingie in the lower right corner. I was unable to get UI Scripting to dependably click the resizing corner, but I did notice that two clicks on the zoom button, after setting a window’s size, toggles between the set size and the zoomed size. So I specified my desired window size, then had System Events click the zoom button (button 2) twice:

set bounds of window 1 to {50, 75, 580, 680}
tell application "System Events" to tell process "Finder" to click button 2 of window 1
tell application "System Events" to tell process "Finder" to click button 2 of window 1

Forcing .DS_STORE to Record Icon Positions

The Finder’s .DS_STORE files are a bit of a mystery. The binary format is closed and there is no programatic way of forcing these files to update. Some smart people have suggested some harebrained workarounds for dealing with this problem, but I wanted something cleaner and more flexible.

My solution was to start fresh by obliterating any .DS_STORE files that might be on the disk image; this appears in the window-layout script before doing anything else:

do shell script "rm " & quoted form of POSIX path of dmgPath & ".DS_STORE"

Next the window is sized, icons are positioned and background image is assigned. Then the script waits to eject the disk* until the .DS_STORE file has been created (open in Script Editor):

set waitTime to 0
set ejectMe to false
repeat while ejectMe is false
    delay 1
    set waitTime to waitTime + 1
    if (do shell script "[ -f " & quoted form of POSIX path of dmgPath & ".DS_STORE ]; echo $?") = "0" then set ejectMe to true
end repeat
log "waited " & waitTime & " seconds for .DS_STORE to be created."
eject dmgPath

On my MacBook Pro, it usually takes 4 seconds for the file to appear. First deleting the file makes sure that the resulting file contains all the new placement information.

Next the disk image gets run through DropDMG and is ready for uploading. I’m ejecting the disk image before converting because I’m getting filesystem errors when I try converting while the source DMG is still mounted. I don’t remember that happening in the past, but it’s probably a good idea to eject first anyway.

Aaron Harnly’s Letterbox addon for Apple’s Mail.app:

Letterbox is a plugin for Apple’s Mail.app that takes advantage of your widescreen monitor. It rearranges the interface into three vertical columns —so the message pane is to the right of the message list, rather than below.

This makes me so, so happy. I had this working in previous versions of OSX and it was one of the first things I tried after upgrading to 10.4.. Seeing more messages is a big productivity boost for me because things that need attention don’t get pushed out of sight.
I’m glad someone finally got it working, thank you Aaron. I hope he does eventually post the source code, I’m curious to see how he did it (and if it changed from the Ars posting).

update URL updated.

I got an email over the weekend pointing out a bug in my iPhoto Date Reset if an original image contained a single-quote in its name. Most all of my iPhoto images were imported from the camera, so I hadn’t seen this before, but I’m pretty sure I’ve already gotten it fixed.

While fixing that, I did a little revising of the EXIF sniffing script. I was using a one-line Perl snippet to scrape the date out of the first kilobyte of the file. Here’s the command broken across several lines

 perl -e 'open(IMG, q:[ABSOLUTE PATH}:);
 read(IMG, $exif, 1024); 
 $exif =~ s/\n/ /g; 
 $exif =~ s/.*([0-9]{4}(?::[0-9]{2}){2} [0-9]{2}(?::[0-9]{2}){2}).*$/$1/g;
 print STDOUT $exif;'

That worked, but perl one-liners usually need to be enclosed in single-quotes, since AppleScript was filling in the path, single-quotes in the name broke the script. I’m not that fluent in Perl, so there’re probably better ways of doing that.

But then I stumbled across the Unix Strings command. This basically does most of what I was doing. It scrapes a binary file (meaning non-text) and extracts anything that seems to be a string. The output from JPEGs often contains a bunch of gibberish, but right above the gibberish is every unencoded string from the EXIF header.

Using strings, sed for the pattern and head to trim, that somewhat convoluted perl script became this trim little shell script:

 strings [ABSOLUTE PATH] | sed -E -n '/([0-9]{4}(:[0-9]{2}){2} [0-9]{2}(:[0-9]{2}){2})/p' | head -n1

They’re both essentially instant on my computer so I’m not going to bother building a test to figure out which is actually faster.

AppleScript’s URL Protocol Support allows the full source code of an AppleScript to be shared through an encoded URL. Here’s a short little TextMate Command for converting AppleScripts to encoded URLs.

Create a new command in TextMate’s AppleScript bundle with the following code:

#!/usr/bin/env ruby -KA -rcgi
src = CGI.escape(STDIN.read)
src = src.gsub('+', '%20')
src = 'applescript://com.apple.scripteditor?action=new&script=' + src
`echo -n "#{src}" | pbcopy`
print "The URL encoded AppleScript was copied to the clipboard"

There’s no reason this idea can’t be used for all sorts of stuff. So why not make it easier, it’s not AppleScript, but here’s that code in Script Editor for easier copying.

This is exceptionally fast, much faster than Apple’s provided encoding script. As an extreme example, converting the 558 lines of my iPhoto Date Reset script took just under a minute using Apple’s script. The little Ruby script in TextMate does it instantly. (running the AppleScript in Script Editor with the Event Log Window open took nearly 7 minutes.)

Update: I committed this command to the TextMate Bundles repository and it’s now included in the default set of Bundles shipping with TextMate. (And slightly improved by other TextMate bundle developers)