Why is a Space character a problem?

A short detour is in order, I presume. The Mac (and the iPhone/iPad) encourage you to name things naturally, so instead of MYGRIDEA.TXT Mac users tend to use My great ideas.txt as filename, the same holds true for directory names. OS X is able to deal with spaces in filenames or paths without problems, the UNIX-underpinnings not so much. This means, should you try to feed the latter filename to a shell command, interesting things will happen.

Open AppleScript Editor and type the following line

set myFileName to "My great ideas.txt"

and click “Run” to see the result in the lower pane of the editor window. I should look like this: "My great ideas.txt".

Now if you want to hand this filename over to a command like print, grep, etc. then these programs will see not one single argument but three arguments:

1. My
2. great
3. ideas.txt

because the space character is used as a so called delimiter, thus separating (or splitting) your filename into three arguments to the program.

How does AppleScript helps me dealing with Spaces?

Good question, simple answer: Just tell AppleScript to do so. The magic happens by using quoted form of. For example

set myFileName to quoted form of "My great ideas.txt"

gives you the following result: "'My great ideas.txt'". The key here is the quoting done by ', these single quotes will be handed over to the program as part of the argument, thus telling the program to leave the spaces inside the quotes alone.

I told you, you just have to ask.

Now I have to figure out which one to use.

If you follow this link, then you will find, and I quote: “Over 1300 sound effects” and “Additional presets for the Space Designer plug-in”, courtesy of Apple (about 640 MB to download).

If you are more of the Motion-type, then following this link allows you to access about 1.15 GB of Motion-goodness like Templates, Graphics, and sample media.

May the bandwith-cap-defying™ deity of your choice be with you.

I needed to create a document with an asymmetric bleed (nope, I won’t discuss if that makes sense). Doing so in InDesign is quite simple. Just tell the document preferences what you need:

set document bleed bottom offset to "3mm"
set document bleed top offset to "3mm"
set document bleed inside or left offset to "0mm"
set document bleed outside or right offset to "3mm"

When the document showed though, the bleed was the same for all four sides of the page. I checked the code, there should be no bleed on the left, but the program stubbornly refused to do what it was told. I then checked the dialog to set the bleed and lo and behold, setting the bleed manually didn’t work either. There is a default setting to make the bleed uniform, no matter what.

The innocent (and active) chain-symbol next to the values gave me a clue: InDesign does not switch to non-uniform just because I told it so, it needs more convincing. Some rummaging in the dictionary using AppleScript Editor later and I found a property called document bleed uniform size. I added the following line before setting the bleed:

set document bleed uniform size to false

And I got what I wanted. The working block of code needs to be in that order:

set document bleed uniform size to false
set document bleed bottom offset to "3mm"
set document bleed top offset to "3mm"
set document bleed inside or left offset to "0mm"
set document bleed outside or right offset to "3mm"

Lesson learned: Always be concise when telling InDesign what you expect.

Every program/script should write its messages to a logfile, period. It just makes sense to be able to figure out what happened or went wrong after the fact. So far, so obvious. A program or script usually takes advantage of, either some kind of framework to write the logs, or relays the work — by using STDOUT and STDERR — to the executing shell. (I know I’m simplifying here, but bear with me.) Let’s assume, that we are using a bash-script, controlled by launchd, to do some work and relay the logging to the shell. Meaning we use echo inside the script to write out diagnostic messages like so:

echo "`date +"%b %d %Y %H:%M"` $0: Everything is peachy."

We write the date and time, the name of the program, and the message we want to convey. When run on the command-line, the message shows up in the terminal. When run via launchd there is no STDOUT to write to; the string probably ends up in the system.log and we have to search for it. Enter the magic of launchd.

The PropertyList-1.0.dtd for launchd luckily contains two keys to make our life easier, the first one is called StandardOutPath and is used inside a launchd-plist like so:

<key>StandardOutPath</key>
<string>/var/log/progname.log</string>

launchd interprets this key and string as “if there is something written to STDOUT, then write it to the file pointed to by the string.” In the example above to the file /var/log/progname.log. Great, but what about the errors? Glad you asked.

The second key is called StandardErrorPath and will process everything written to STDERR.

<key>StandardErrorPath</key>
<string>/var/log/progname_err.log</string>

You could use the same file for both by using the same filename, should you be inclined to do so. I prefer to separate the messages.

Happy logging everyone.

Don’t you hate it when posts like this do not contain a full example? I do. So here it goes:

The bash-script (named sillyscript.sh) doesn’t do much, but you get the idea:

#!/usr/bin/env bash
MYLOGLINE="`date +"%b %d %Y %H:%M"` $0:"
echo "$MYLOGLINE I’m alive!"
#uncomment to create an error
#cp /testfoobar /tmp/`

And here is a simple launchd-plist to put the script in action:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>label</key>
<string>com.erikslab.sillyscript</string>
<key>ProgramArguments</key>
<array>
<string>/Users/Shared/sillyscript/sillyscript.sh</string>
</array>
<key>StandardErrorPath</key>
<string>/Users/Shared/sillyscript/sillyscript_err.log</string>
<key>StandardOutPath</key>
<string>/Users/Shared/sillyscript/sillyscript.log</string>
<key>StartInterval</key>
<integer>120</integer>
</dict>
</plist>

Note that everything takes place in a folder named sillyscript located in /Users/Shared, meaning if you want to start trying using the example shown, you would have to create that folder.

Now back to work. What? Still not satisfied? OK.

Use

launchctl load ~/Library/LaunchAgents/com.erikslab.sillyscript.plist

(after copying the file com.erikslab.sillyscript.plist to ~/Library/LaunchAgents of course) and watch your logfile in /Users/Shared/sillyscript/ grow in two-minute intervals.

Again, happy logging everyone. (And don’t forget to launchctl unload and remove the plist after you are done playing with it. )

One of the most used constructs would be accessing the folder Documents located in the user’s $HOME, for example. The easiest way is the following string of commands:

set myDocumentFolder to path to documents folder as string

The result is the colon-delimited path as string, e.g. MacHD:Users:username:Documents:.

If you need the path to hand it over to a shell script or any other process requiring the Unix way of wording a path, use this approach:

set myDocumentFolder to POSIX path of (path to documents folder as string)

No surprise here, the answer will be something like this: /Users/username/Documents.

But what about accessing the user’s Library folder? If we continue like this:

set myUserLib to path to library folder as string

All we get is MacHD:Library:. Is there a way to tell AppleScript which Library folder we are really interested in? There sure is:

set myUserLib to path to library folder from user domain as string

Firing this command results in the path we are looking for: MacHD:Users:username:Library:. Telling AppleScript the domain we are interested in does the trick.

There are three domains at our disposal (there are actually some more, but those will be the subject of another post):

• user
• local
• system

To cut a long story short, here are examples for the other two domains and the corresponding results:

• set myLocalLib to path to library folder from local domain as string returns MacHD:Library:
• set mySystemLib to path to library folder from system domain as string returns MacHD:System:Library:

It seems, that using from local domain is superfluous in regard of the folder Library, but good programming practice (and the resulting peace of mind) implies, that we should use the construct and be save from surprises later.

If you want to open the Sound-Pane in System Preferences then try this key combination:

⌥ – any of the keycaps to modify the volume on your Mac

The same goes for the Monitors-Pane:

⌥ – keycap to increase or decrease monitor backlight

Just a quick tip for the impatient. Works in 10.5.x and 10.6.x.

Get the whole story on Wikipedia or from the BBC.

It seems that it is not that widely known, that you are able to launch Dashboard via AppleScript, as well. If you got an error message like ‘Dashboard got an error: Application isn’t running.’ while using activate, launch does the trick. It is as simple as that:

tell application "Dashboard"
	launch
end tell

Bonus: If you are administering one or more OS X servers, then check your available Widgets in Dashboard, there is one to give you information about the vitals of your server(s).

cron, the one available on OS X, is capable of handling the switch from daylight time to ‘normal’ without problems. Meaning jobs starting between 2 AM and 3AM won’t run twice. I always thought, that this behavior is built into launchd as well. Long story short: Three OS X Servers started the jobs twice last weekend.

Just an FYI in case you need to know.