Volume Number: 23 (2007)
Issue Number: 07
Column Tag: MacEnterprise
By Philip Rinehart, Yale University
As with any Unix operating system, Macintosh OS X recognizes the use of environment variables. For a quick refresher, environment variables are traditionally used in shell scripts to retrieve information about the operating environment. Common environment variables are used each time a new Terminal session is launched, including PATH, HOME, and other less common variables. OS X extends this concept with application bundles and Launch Services. Let's begin by examining the traditional use of environment variables by OS X and their associated scope.
The single most common invocation of environment variables is when the Terminal application is launched. Each time a new shell is opened by the Terminal application, a new session is created with system wide environment variables. Let's look at the two environment variables that are created for each session in a standard Tiger installation.
PATH
The PATH environment variable is probably the single most common variable that is changed in any terminal session. In a standard OS X installation, the file /etc/profile is used to set the PATH variable. It is also used for any remote session when connected to any remote machine with ssh. By default, the variable is set at PATH="/bin:/sbin:
/usr/bin:/usr/sbin". Why might one change this default value? What if useful binaries live in other directories?
As an example, a standard fink or macports installation installs binaries either in /sw or /opt/local/bin. In this case, the modification of profile to reflect the directory is important. For Macports, open profile in an editor and add /opt/local/bin to the PATH. Any session created with the Terminal application or via ssh will now search the PATH including /opt/local/bin. Any binary that has been installed in /opt/local/bin is now available to a Terminal session or a remote ssh session.
One quick note: be careful when setting the PATH system wide, as the PATH is searched beginning with the first directory listed. When installing macports, or fink for that matter, if the directory is listed first, the binaries installed by these collections are used first. This might be problematic if the system binary is what is desired when calling any program.
PS1
PS1 is created for each new Terminal window through use a second file in /etc, bashrc. This file creates the custom command prompt, showing hostname, current working directory, and username. This file can also be altered, as profile can, so that any user logging into the system has an identical command prompt. Note though, the bashrc file is only read when using the bash shell (the default shell in OS X 10.4), not when using other shells such as tcsh, or zsh.
One last bit about OS X, and the use of the Terminal application. Environment variables can be set in any Terminal window. It is important to note that any newly set environment variables are not inherited if a new shell session is invoked, and cannot, therefore, be depended on. For this reason, it is best practice, at least, to edit profile to apply environment variables for each user on the host operating system.
OS X has the unique ability to use a plist stored in ~/.MacOSX/environment.plist to access any environment variable. The plist is registered by loginwindow, so that non-Terminal based applications could use environment variables for their operation. However, one environment variable, DYLD_LIBRARY_PATH, was noted as a security risk in Security Update 2007-004. As noted on the MacEnterprise list, the change in behavior affected some applications, most notably the IBM Workplace Forms Viewer, used for governmental grant applications. If the environment.plist method is subject to change, is there a more reliable method to access environment variables? Yes, application specific environment variables!
Prior to launching any application, environment variables can be set in the info.plist file within an application bundle. Launch Services then reads the environment variable, and uses it for dynamic configuration of the application. This method is exactly what was used from a suggestion by Josh Wisenbaker, and implemented by Ben Hanes. Let's look at how it works.
By default, an application created in XCode includes a bare bones Info.plist file. The file contains basic information about the application bundle. It commonly contains information about the application, copyright, icon file information as well as other application specific information. It really is up to the developer to specify information as listed in the Apple Runtime Configuration Guidelines. For the purpose of this article, the particular key of interest is LSEnvironment. It is a dictionary value, and contains a complete list of environment variables that are read prior to launch of the application bundle. Launch Services reads the variables, and uses them when the application is launched. It is important to note, this use of environment variable only works when the application is launched from the Finder. Let's return to the example application that created problems to see how this works in practice.
The first step is opening the application bundle. Most bundles are similar to Figure 1 below.
Figure 1.
The file that needs to be edited for any application bundle to register an environment variable is Info.plist. Opening the IBM Workplace Forms Viewer Info.plist, add the environment variables required by this application. Here is the relevant dictionary that is added:
<key>LSEnvironment</key>
<dict>
<key>DYLD_LIBRARY_PATH</key>
<string>/Applications/IBM Workplace Forms/IBM Workplace Forms Viewer.app/Contents/¬
MacOS:/Applications/IBM Workplace Forms/IBM Workplace Forms Viewer.app/Contents/¬
MacOS/API/70/system</string>
<key>PUREEDGE_INI</key>
<string>/Applications/IBM Workplace Forms/IBM Workplace Forms Viewer.app/Contents/MacOS/PureEdgeAPI.ini</string>
</dict>
Take a close look, the key is specified in this example as documented by Apple's Developer documentation, LSEnvironment. Two separate environmental variables are then set, DYLD_LIBRARY_PATH, and PUREEDGE_INI. Other applications can use this exact method, including SyBase SQL Anywhere 9 and USAnimation's Harmony.
Armed with the knowledge of how to set environment variables, both for the terminal and for Finder based applications, it should be trivial to correct applications which do not function as expected if environment variables are not set. Until next month, see you on the lists!
Philip Rinehart is co-chair of the steering committee leading the Mac OS X Enterprise Project (macenterprise.org) and is the Lead Mac Analyst at Yale University. He has been using Macintosh Computers since the days of the Macintosh SE, and Mac OS X since its Developer Preview Release. Before coming to Yale, he worked as a Unix system administrator for a dot-com company. He can be reached at: philip.rinehart@yale.edu.
The MacEnterprise project is a community of IT professionals sharing information and solutions to support Macs in an enterprise. We collaborate on the deployment, management, and integration of Mac OS X client and server computers into multi-platform computing environments.
