Check all AutoPkg Recipes

AutoPkg needs to load all recipes in the search paths on every run so it can locate recipes and their parents (which may be spread over different repositories).

Because of this, AutoPkg may fail if a single recipe has malformed property list syntax. To locate the one broken property list among many, you can use the following command:

$ find ~/Library/AutoPkg -name "*.recipe" -exec plutil -lint {} \; | grep -v "OK$"

This uses find to find all files with the .recipe file extension in the AutoPkg folder and executes plutil -lint filename, then it uses grep to show only lines not (-v) ending with ‘OK’.

Some Useful AutoPkg Processors

I have updated some of the shared processors in my AutoPkg repository. I find them useful for my AutoPkg workflow and testing recipes. I hope they may be useful for you, too.

You can find more detailed information on the processors in the scriptingosx-recipes repository. To add the repository to your AutoPkg use this command

$ autopkg repo-add scriptingosx-recipes


This processor can be used to read a file with placeholder variables and write the result to a new file (presumably in the package being built). I use the FileTemplate processor in the FirefoxPrefs.pkg recipe to insert a javascript settings file with the proper values.

String sequences in the template file which are enclosed with % symbols such as %version% or %homepage_url% will be replaced with the value from the autopkg variable. You can use variables defined or obtained in previous recipe steps (e.g. %version% or %NAME%) or add additional values as input variables for the FileTemplate processor (see homepage_url in FirefoxPrefs.pkg)

See the firefox_AA.cfg.template file for an example.

Note: this is a very basic way of setting Firefox preferences. It works great for my use case (supressing update dialogs and setting home page url in student labs). If you need more control over Firefox behavior in your packaging process, look at CCK and use Greg’s FirefoxAutoconfig recipes.

Post Processors

The other processors are designed to be run as post-processors. You can add them to your AutoPkg workflow like this:

$ autopkg run Recipe1.pkg Recipe2.pkg --post com.scriptingosx.processors/Notification

Or with a plist format recipe list.

These are fairly simple post-processors. They can serve as a useful example for how to write and use post-processors.


This will show a user notification when the processor detects a new download or that a new package was built. (May act strangely when run with no user logged in.)


This processor will open a new Finder window and reveal (select) the new file. It will either use a newly archived file, a newly built package or a new download (in that order). (May not work when no user is logged in.)


When this processor detects a new download or that a new package was built it will copy it to a the directory given in archive_path. archive_path can be on a file server, but it is your responsibility that the share is mounted and available at that path. When the processor determines that a package was built it will copy that, otherwise it will look for a downloaded file. Existing files with the same name will be overwritten.

Even when you don’t copy to a server this can be useful to create an archive of packages outside of the ~/Library/AutoPkg/Caches folder so you can delete cache folders to remove problems with downloads or package building without losing your ‘history’ of packages.

To provide the required archive_path variable you can use the -k/--key argument or a plist format recipe list.

$ autopkg run Recipe1.pkg Recipe2.pkg --post com.scriptingosx.processors/Archive -k archive_path=~/Library/AutoPkg/Archive/ -k archive_subdir=%NAME%

Useful AutoPkg bash functions

Note: the version of these functions I posted originally were not safe for paths with spaces in them. I have updated them and now the should be.

I have added these functions to my .bash_profile and thought they might be useful for others as well.

alias reveal="open -R"

function recipe-open() { open "$(autopkg info $@ | grep 'Recipe file path' | cut -c 22-)"; }
function recipe-edit() { bbedit "$(autopkg info $@ | grep 'Recipe file path' | cut -c 22-)"; }
function recipe-reveal() { reveal "$(autopkg info $@ | grep 'Recipe file path' | cut -c 22-)"; }

Use them like this

recipe-open RecipeName.munki

recipe-open will grab the path to the recipe file and use open to open it with its default application. I have PlistEdit Pro assigned to open .recipe file extensions.

recipe-edit will open the recipe file in BBEdit, which doesn’t suck.

recipe-reveal will open the recipe in the Finder. The bash alias reveal for open -R is quite useful independent of autopkg.

Adapt for your own choice of editors.