Relocatable Package Installers and quickpkg Update

In my book “Packaging for Apple Administrators” I show a great use of pkgbuild to wrap an application in a package installer:

$ pkgbuild --component /Applications/ Numbers.pkg

If the application is not already in the /Applications folder, you have to add the --install-location:

$ pkgbuild --component /Volumes/Firefox/ --install-location /Applications Firefox.pkg

This is great and wonderful, but has one drawback: the installers pkgbuild creates this way are ‘relocatable’. When the installer does not find the application in the target location, it will look if the application is installed elsewhere on the system. If it finds the ‘relocated’ application bundle, it will happily try to update it in the new location.

Usually this is not a big problem on managed systems. However, if users have copies of applications in unusual locations, e.g., because they do not have permission to install in /Applications or because they themselves are admins with dozens of versions in ~/Library/AutoPkg, then this can lead to unexpected behavior or failure.

The common solution to this is to create ‘non-relocatable’ installer packages.

What makes a pkg relocatable

The relocate element in the PackageInfo file in an installer package controls this behavior. You can see the PackageInfo file in Pacifist or with pkgutil:

$ pkgutil --expand Firefox.pkg Firefox_expanded
$ more Firefox_expanded/PackageInfo 

Among much other data you will see this xml element:

    <bundle id="org.mozilla.firefox"/>

This tells the Installer to look for an application bundle with the given identifier and install in that location. To disable this, you can replace the above element with an empty relocate element:


Then installer will install or upgrade in the given install-location (e.g. /Applications) only.

You can apply this change to the expanded PackageInfo file with a text editor and re-create the pkg file with

$ pkgutil --flatten Firefox_expanded/ Firefox-nr.pkg

(‘nr’ for ‘non-relocatable’)

However, applying these steps after creating each package is tedious and error-prone, so we want to look for a better solution.

Telling pkgbuild to not re-locate

The pkgbuild man page mentions there is an option to create non-relocatable installer pkgs with the BundleIsRelocatable option in a ‘component property list’. This is great, since it is better to use documented options, rather than hacking the PackageInfo directly. However, to use the --component-plist option with pkgbuild you have to use the --root option rather than the --component option This requires a bit more effort.

First create a project folder:

$ mkdir -p Firefox/payload
$ cd Firefox

And copy the application to the payload directory:

$ cp -R /Volumes/Firefox/ payload/

Then you can use pkgbuild’s --analyze to create a template component property list:

$ pkgbuild --analyze --root payload Firefox-component.plist
pkgbuild: Inferring bundle components from contents of payload
pkgbuild: Writing new component property list to Firefox-component.plist

You can then open the generated property list file in a text or property list editor. You will see several values for different settings and a list of ChildBundles. Change the value of the BundleIsRelocatable key from <true/> to <false/>. You can do this in the editor or with the plutil command:

$ plutil -replace BundleIsRelocatable -bool NO Firefox-component.plist

Then build the package with pkgbuild:

$  pkgbuild --root payload --identifier org.mozilla.firefox --version 53.0.3 --install-location /Applications --component-plist Firefox-component.plist Firefox-53.0.3.pkg

This will build the package installer with an empty relocate element.

Note: munki-pkg has an option suppress-bundle-relocation which achieves the same result.


This approach can be useful but is still complicated. To simplify the creation I have updated my quickpkg tool to create non-relocatable packages by default. You can change the new default behavior with the --relocatable option.

$ quickpkg ~/Downloads/Firefox\ 53.0.3.dmg 


Tab Completion for autopkg

Tony Williams aka ‘honestpuck’ has built a script to enable tab-completion for autopkg in bash.

This means that you can type

$ autopkg s⇥

(where ⇥ is the tab key) and it will autocomplete to

$ autopkg search 

This will also work for recipe names:

$ autopkg run BBEdit⇥⇥  BBEdit.jss       BBEdit.pkg       
BBEdit.install   BBEdit.munki     

This is really useful. Auto-completion not only saves on typing, but helps to avoid errors.

Installing autocompletion in your profile

Tony has provided instructions on how to install the script with brew. However, it not hard to install this manually in your .bash_profile or .bashrc. First, clone the github repository on to your system (I keep all projects like this in an un-creatively named ‘Projects’ folder):

$ cd ~/Projects
$ git clone

This will download the project to autopkg_create. The file we need is the autopkg file inside that folder.

Then add the following lines to your .bash_profile or .bashrc:

if [[ -r "$HOME/Projects/autopkg_complete/autopkg" ]]; then
    source "$HOME/Projects/autopkg_complete/autopkg"

You will need to adjust the path if you are using a different location. Basically these lines say: if this file exists and is readable, then read and interpret it as bash source. Since you need to define functions in the context of the shell, you need to `source` the file, rather execute it as script. (When you run the the file as a script, the functions will be defined in the context of the script, and then ‘forgotten’ when the script ends.)

Save your new profile and open a new Terminal window or type

$ source ~/.bash_profile

to update an existing shell.

Thanks again to Tony Williams, this is very useful!

Typefaces for Coding and Terminal

Since the previous posts were about customizing the shell for shell I thought I’d update an older post and look at some monospaced fonts suitable for Terminal and text editors to get a change from Menlo.

Not so serious, but fun…

C64 TrueType is a fun addition at the end. As the name implies this font recreates the 8-pixel characters from the C64. Together with some extra settings in Terminal and your bash_profile you can take your terminal back to the 80s.

If you have been following along my lose series on Terminal in macOS, this serves as a nice example of some more exotic Terminal customization.

MacSysAdmin 2017 Conference Open for Registration

You can now register for the MacSysAdmin Conference in Göteborg (Sweden) which will go from October 3-6.

It is a great conference and I have wanted to go for years, but never managed to make it. The list of speaker has been and is really very impressive.

So I am very proud to announce that not only will I be attending but also presenting a session on macOS bash scripting this year! (so literally a session on ‘Scripting OS X… macOS’)

Looking forward to seeing you all there!

Weekly News Summary for Admins – 2017-04-07

On Scripting OS X

Mac Pro: Signs of Life

This week’s big surprise is that Apple has let out some early news that they are working on a new Mac Pro. Even more interesting than new hardware is (for me) that Apple is trying to re-assure the pro and prosumer market that Apple cares about them.

Micheal Tsai has a great summary post.

Other News

To Listen

On Viewing `man` Pages

When you frequently use Terminal, you will use man pages. They contain tons of useful information on most of the tools and commands you use on the shell.

However, the man command’s user interface was designed for terminal output decades ago and does not really integrate well with the modern macOS UI. When you run the man command the output will take over your current Terminal window and scrolling through long man pages can be tedious.

Normal man page in Terminal


However, on macOS you do not have to man like it’s 1989.

First solution is to use

$ open x-man-page://ls

instead of man. This will open the man page in a new yellow Terminal window, so you can still see what you are actually doing, while reading the man page. If the yellow is just too annoying for you, you can change the look of the window by changing the ‘Man Page’ window profile in the Terminal Preferences. Since this window shows the entire man page, you can scroll and even use ‘Find’ (Command-F) in this window.

The beautiful yellow x-man-page window

Since typing this open command is a bit awkward, you can add a function to your bash profile or bashrc file:

function xmanpage() { open x-man-page://$@ ; }

Note: You could use xman here. However, that will conflict with another command when you have X11/XQuartz installed.

You can also put ‘x-man-page:’ URLs in other applications, such as emails or chat applications. However, not all applications will recognize URLs starting with x-man-page: as URLs, so your results may be mixed. It does work in Slack, even though Slack is skeptic of the links:

Slack will warn you about unusual links

Taken from Context

In Terminal, you can open a man page from the context menu. Simply do a secondary (ctrl/right/two-finger) click on a word in a Terminal window and choose ‘Open man Page’ from the context menu. This will open the man page in a separate window, like opening x-man-page URLs.

Open man Page in the Terminal context menu

man Page with a (Pre)view

Back in the early days of computing you could (or had to) convert man pages into postscript output, so they would look nicer when printing. These options are still present and we can (ab)use them to show a man page in Preview. (Please don’t waste paper printing man pages.) The command for this is:

$ man -t ls | open -f -a "Preview"
Preview showing a man page

The -t options pipes the man page into another tool (groff) to reformat it into pdf which we then pipe into open and send to the Preview application. (More on the open command.) If you use this more frequently, you want to create a function for this in your bash profile or .bashrc:

function preman() { man -t "$@" | open -f -a "Preview" ;}

Text Editors

You can also send a man page to a tex editor. Before you pipe the output into a text editor, you have to clean it up a bit:

$ MANWIDTH=80 MANPAGER='col -bx' man $@ | open -f

This will open in TextEdit. If your favored text editor can receive data from stdin, then replace the open -f with its command. For BBEdit, this will work great:

$ MANWIDTH=80 MANPAGER='col -bx' man $@ | bbedit --clean --view-top -t "man $@"

And again, if want to use this method frequently, create a bash function for it.


The ManOpen application has been around for a long, long time, but amazingly, it still works on macOS Sierra. It will also display man pages in a separate window. The main advantage MacOpen has over the other solutions here is that it will automatically detect other commands and highlight them as hyperlinks to their man pages. There is also a command line tool, confusingly called openman to open the app directly from the Terminal.


You can also create an Automator Service for this. Then you can open man pages from (nearly) any application with a keystroke or from the context menu. I described this in an older post on man pages.

Weekly News Summary for Admins – 2017-04-03

On ScriptingOSX

Posts and News


The updates for macOS 10.12.4, iOS 10.3 watchOS and tvOS(!) dropped this week. Lot’s of Apple support pages to catch up with:

To Watch

To Listen

New options for macOS Recovery

Mike Boylan on Twitter points to this new Apple Support article on re-installing your Mac. The option for restoring from internet recovery have changed:

Reinstall the latest macOS that was installed on your Mac, without upgrading to a later version.1
Upgrade to the latest macOS that is compatible with your Mac.2
Requires macOS Sierra 10.12.4 or later. Reinstall the macOS that came with your Mac, or the version closest to it that is still available.