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.

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.

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. )

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.

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.

• Don’t panic!
• There might be a way out of this.

What happened?

The passwords for the administrative account on OS X Server, I’m talking about the one created during installation, and the diradmin-account are the same, right? Are you sure? They probably are, if you didn’t change one of them. These two passwords are the same after the installation, because they have been synchronized during the installation. If you should change one of them later, then they won’t be synced again. Shouldn’t be a problem, though, everyone keeps records of vital data like this, most of the time.

On the other hand, if one of us sets up a machine, then said machine should get a healthy workout before deployment, to make sure the hardware is OK. This usually includes the installation and configuration of all needed hard- and software. So, in theory, the machine would be ready for deployment. But, during these tests, nobody cares about passwords; the system runs in a controlled environment and access from outside of this environment is either impossible or severely restricted. This could mean—if the Open Directory-user-accounts have been created during this phase—that nobody tried to connect to the directory-tree as diradmin after the change to the “real” administrative password. Same goes for periodic changes to the administrative password, depending on your policy.

It happened, I cannot login as diradmin any more…

Regardless how it happened, don’t do anything in a rush now; breathe. Spare yourself the trouble to try passwd diradmin as super-user, it won’t work; you need the old password to make changes. If you have access to the system, either physically or via ssh, ARD or screen-sharing, then the situation can be rectified.

If possible, make a backup of the system, seriously! Then retrace the steps in How to reset the Open Directory administrator password and you should be OK.

In a nutshell: The documents describes how to use Workgroup Manager to gather information about the password and uses mkpassdb to dump the password-database and overwrite the old password with a new one. It seems, that on 10.5 all you need to do is to use

sudo mkpassdb -dump

to get the slot-ID and

mkpassdb -setpassword [slot-ID]

executed as super-user, a.k.a. root (one way to get there is sudo su), to create a new password for diradmin.

The latter is my experience, your mileage my vary.

Disclaimer: The fact that it worked for me, does not necessarily mean it will work for you. You have to do it on your own risk, I’m not responsible if something goes wrong.

sudo tcpdump host [ip-address]

It lists the packets as they go by, regardless if [ip-address] is the source or the destination. The use of sudo is a necessity on OS X, you’ll end up with a tcpdump: no suitable device found-message otherwise and rightly so, “normal” users have no rights to snoop tpcdump packets.

The former is the location for Scripts available to the user of the account, the latter for all users of a machine. Don’t get fooled by the fact that you are able to choose any script via the context-menu of a folder if Folder Actions are enabled.

Just in case you need to know.

diskutil list

The device-node in question is in the column titled IDENTIFIER. The device-path to use is the one with the name of the volume, e.g. if the column reads disk0s2, then the command would be:

diskutil repairPermissions /dev/disk0s2

You should see some kind of progress-bar in ASCII.

One thing to note though: Using the command does not prevent the “meditation” of the program after 20%. I’d be interested what the system is doing while it seems to mull over something when it is supposed to repair the permissions.