Weekly News Summary for Admins – 2017-05-26

On Scripting OS X

To support Scripting OS X, consider buying one (or both) of my books. Thank you!

If you have already bought and read the books, please leave a review on the iBooks Store. Reviews are important to help new potential readers make the purchase decision. Thank you (again)!

Updates and Releases

Posts and Opinion

Support and HowTos

To Listen

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.app Numbers.pkg

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

$ pkgbuild --component /Volumes/Firefox/Firefox.app --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/Firefox.app 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 


Weekly News Summary for Admins – 2017-05-20

On Scripting OS X

To support Scripting OS X, consider buying one (or both) of my books. Thank you!

If you have already bought and read the books, please leave a review on the iBooks Store. Reviews are important to help new potential readers make the purchase decision. Thank you (again)!

Updates and Releases

Posts and Opinion

Support and HowTos


To Listen

Things 3 is out!

My favorite to-do-list manager that I keep returning to has gotten the long awaited update!
Things 3 from Cultured Code is out.

I have been using the beta for a while now and just love the application. Things 3 has plenty of features, but also a gorgeous and clean interface.

You can download a trial for the Mac version from their website. You can purchase the Mac, iPhone and iPad versions from the respective AppStores. Currently the app is on 20% introductory sale until May 25.

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.download  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 https://github.com/Honestpuck/autopkg_complete.git

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!

Weekly News Summary for Admins – 2017-05-12

On Scripting OS X

To support Scripting OS X, consider buying one (or both) of my books. Thank you!

If you have already bought and read the books, please leave a review on the iBooks Store. Reviews are important to help new potential readers make the purchase decision. Thank you (again)!

Updates and Releases

Posts and Opinion

Support and HowTos

To Listen

Where PATHs come from

In an earlier post we talked about how to append to the PATH variable, so you can add your own directories to bash’s search path.

In macOS the default PATH on a ‘clean’ installation is:

$ echo $PATH

However, if you have installed some tools (such as the macOS Server.app, Xquartz or Munki) you will see those in the PATH as well:

$ echo $PATH

Where does this pre-set PATH come from?

Since the PATH is pre-set on a clean new account without a .bashrc or .bash_profile, we have to look in a central location which applies to all users. In another earlier post, we saw that /etc/profile is run for every user shell, even before a .bash_profile is executed. When you look into this file, you see that the very first set of commands look like this:

if [ -x /usr/libexec/path_helper ]; then
    eval `/usr/libexec/path_helper -s`

This looks very promising. The path_helper tool has a man page. This tool does a few things to assemble the PATH. First it reads the file /etc/paths which on macOS looks like this:


So this is where the default ‘clean’ macOS PATH comes from. Then path_helper will read every file from /etc/paths.d and append each line of each file in that directory to the PATH as well. This is where optional and third party applications and tools, like Xquartz or Munki, can install their own additions to the PATH for all users.

(Files in this folder will be read in alpha-numerical order of the filename. Some tools, like Xquartz, attempt to influence the order by preprending a number, e.g. 40-XQuartz.)

Finally, if path_helper runs in an environment where PATH is already set, it will append that PATH value to what it built from the files and then remove duplicates.

path_helper does not change the environment variable directly, but it generates the commands necessary to set the PATH correctly. It will generate the right commands wether it is called from a bourne type shell (on macOS: sh, bash, ksh and zsh) or a csh type shell (on macOS: csh and tcsh). You can see the output of the two styles by running path_helper with the -s or -c options:

$ /usr/libexec/path_helper -s
PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"; export PATH;
$ /usr/libexec/path_helper -c
setenv PATH "/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin";

(You have to type the full path to path_helper because, ironically, but intentionally, /usr/libexec is not in the standard PATH.)

To actually execute the commands generated by path_helper you can use the eval command, like the /etc/profile does:

$ eval $(/usr/libexec/path_helper)

Don’t touch my Profile!

Some command line tool installers understandably feel the need to add their tools to the default PATH. Since there is no unified approach among different flavors of UNIX and Linux on how to do this, you will find several different approaches. Some tools will edit /etc/profile and others will look for the various profile files in a user’s home directory and edit those. Usually the installation process will append a line that appends their tools directory to the PATH.

One example for this is the Python 3 installer. It contains a compnent package that will attempt to determine which profile file you are using and appends a line to append to the PATH.

However, this is not only highly intrusive but also quite fragile. Changes to /etc/profile might be overwritten by a future macOS update. Changes to a user’s profile file, might be overwritten by the user. Also the installer will only append their setting to the current user, not other users that may be present or created in the system.

Sample paths.d installer package

On the other hand, dropping a file into /etc/paths.d with a package installer will affect all users on a system. The file in paths.d can be updated for future updates if necessary and is also easily identified and removed by an admin. It will work wether it is installed to the startup volume or another volume. It can be pushed with management tools.

Building an installer for a file in /etc/paths.d is very simple:

$ mkdir CustomToolPathInstaller
$ cd CustomToolPathInstaller
$ mkdir payload
$ echo "/usr/local/customtool" >> payload/customtool
$ pkgbuild --root payload --install-location /private/etc/paths.d --version 1.0  --identifier com.example.customtool.path CustomToolPath.pkg
pkgbuild: Inferring bundle components from contents of payload
pkgbuild: Wrote package to CustomToolPath.pkg

Only five commands, three of which create the folder structure. You can find this sample project (which is slightly more elaborate) on my GitHub.

If you want to learn more about building installer packages for macOS, please read my book “Packaging for Apple Administrators”.

What about MANPATH?

This is usually not used on macOS since the the default settings for the man tool are quite flexibel. (Look at the man page for man and the file /etc/man.conf for details.) However, if a MANPATH environment variable is set when path_helper runs, it will also assemble the command to set the MANPATH built in a similar way to the PATH from the files /etc/manpaths and the directory /etc/manpaths.d.

Usually the MANPATH is not set on macOS so you will not see this. But if you want to manage your MANPATH and want to leverage path_helper all you have to do is set the MANPATH.

$ export MANPATH=/usr/share/man
$ /usr/libexec/path_helper
PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"; export PATH;
MANPATH="/usr/share/man:/usr/local/share/man"; export MANPATH;

Re-order the PATH

We have seen path_helper is extremely useful. There is one caveat, however. path_helper may reorder your PATH. Imagine you are pre-pending ~/bin to your PATH because you want to override some standard tools with your own. (Dangerous, but let’s assume you know what you are doing.) Then some process launches a subshell which can call path_helper again. path_helper will ‘find’ your additions to the defined PATH, but it will append to the list of default paths from /etc/paths and /etc/paths.d, changing your order and thus which tools will be used.

$ export PATH=~/bin:$PATH
$ echo $PATH
$ /usr/libexec/path_helper 
PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/armin/bin"; export PATH;

You can see behavior like this when you use Xterm (The X11 based terminal in Xquartz) which does not execute .bash_profile but still picks up the PATHenvironment variable from somewhere…

# in Xquartz Terminal:
bash-3.2$ echo $PATH

A better way to override built-in commands which is not affected by path_helper would be to use bash aliases or functions in your profile.

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.