If you want to run custom scripts or applications when the user logs in, there are several ways to do it. You might use this feature to perform maintenance tasks or set up the operating environment for your own applications when the user first logs in.
To launch an application each time the user logs in, use the Login items found in the Accounts system preference. Login items are appropriate for user-level applications, as opposed to applications that operate on behalf of the system. When you configure an application to be launched as a login item, you must remember that the user can disable the launching of your application via the Accounts system preference. Dependent applications must be able to respond appropriately if they detect the login-item application is not running.
Note: Beginning with Mac OS X v10.5, the recommended method for adding a login item programmatically is with the Shared File Lists API. If your application needs to be compatible with earlier versions of Mac OS X, you should instead add login items with Apple Events. The two additional methods listed here are deprecated and may cease to function with future updates to Mac OS X.
Available in Mac OS X v10.5 and later, the Shared File Lists API can be found in LSSharedFileList.h
in /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/
.
You can easily manipulate the list of login items for the currently logged-in user using Apple events. This technique is described in the sample code LoginItemsAE.
Another technique for working with property lists is through the CFPreferences API in Core Foundation. Like the Apple Events technique, this only works for the current user. Unlike the Apple Events technique, however, that user does not need to be logged in on the console. Thus, this technique can be used to modify preferences for a different user by running this piece of code as that user using a setuid executable.
The following code snippet shows the basics:
CFArrayRef prefCFArrayRef = CFPreferencesCopyAppValue(CFSTR("AutoLaunchedApplicationDictionary"), CFSTR("loginwindow")); |
CFMutableArrayRef tCFMutableArrayRef = CFArrayCreateMutableCopy(NULL, 0, prefCFArrayRef); |
/* Modify tCFMutableArrayRef here */ |
CFPreferencesSetAppValue(CFSTR("AutoLaunchedApplicationDictionary"), tCFMutableArrayRef, CFSTR("loginwindow")); |
For a more complete example, see the CFPreferences sample code. For additional documentation about the API itself, see Core Foundation Framework Reference.
If you need to add applications manually to your list of Login items, you can modify the ~/Library/Preferences/loginwindow.plist
property-list file of the desired user using the Property List Editor. Inside this file, add the desired application to the array of applications listed under the AutoLaunchedApplicationDictionary
key.
For example:
<?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>AutoLaunchedApplicationDictionary</key> |
<array> |
<dict> |
<key>Hide</key> |
<true/> |
<key>Path</key> |
<string>/Applications/iTunes.app/Contents/Resources/iTunesHelper.app</string> |
</dict> |
</array> |
<key>BuildVersionStampAsNumber</key> |
<integer>17371360</integer> |
<key>BuildVersionStampAsString</key> |
<string>8J135</string> |
<key>SystemVersionStampAsNumber</key> |
<integer>168036096</integer> |
<key>SystemVersionStampAsString</key> |
<string>10.4.7</string> |
</dict> |
</plist> |
Note: This file does not exist by default. It is created only when you change a setting from the default (for example, by adding a login item using System Preferences).
Another way to run applications at login time is to launch them using a custom shell script. Mac OS X provides two options for launching scripts when the user logs in. When creating your script file, keep the following in mind:
The permissions for your script file should include execute privileges for the appropriate users.
Scripts launched by loginwindow
are run as root. Therefore, you should thoroughly test your scripts before deploying them to make sure they do not adversely affect the user's system.
In your script, the variable $1
returns the short name of the user who is logging in.
Other login actions wait until your hook finishes executing. Therefore, have your script do what it needs to do quickly and then exit.
Warning: Only one of these hooks can be installed at a time. For this reason, login scripts are not recommended for deployment. This information is provided as an aid to system administrators and should not be deployed in released software.
In Mac OS X v10.3 and later, you can use the defaults
tool to install your login script. This is the preferred technique for installing a login script.
Create the script file and put it in a directory that is accessible to all users. In Terminal, use the following command to install the script (where /path/to/script
is the full path to your script file):
sudo defaults write com.apple.loginwindow LoginHook /path/to/script |
To remove this hook, you simply delete the property as follows:
sudo defaults delete com.apple.loginwindow LoginHook |
When using the sudo
command, you must be an administrator of the current system. When you run the preceding command, sudo
prompts you to enter your password. You must provide a valid password before the hook can be installed.
Note: If no plist
file exists for com.apple.loginwindow
, this method will not work. This file (/var/root/Library/Preferences/com.apple.loginwindow.plist
) does not exist on a fresh installation until the user changes a login window setting (such as turning on fast user switching).
If you must install startup scripts programmatically, you should consider providing a copy of this file containing the default configuration options. Then, if the file does not exist, copy that default configuration file into place before running defaults
. Again, however, this technique is not recommended for use in applications because these hooks cannot coexist.
In Mac OS X v10.2 and v10.3, you can run your startup script by modifying the /etc/ttys
file. In this file is the following line:
console "/System/Library/CoreServices/loginwindow.app/Contents/ |
MacOS/loginwindow" vt100 on secure onoption="/usr/libexec/getty |
std.9600" |
This line tells the init
program to launch loginwindow
on the console terminal. Into this line, you can insert additional parameters for loginwindow
to process. Table 1 lists the parameters that are supported by loginwindow
.
The -LoginHook
and -LogoutHook
parameters were particularly useful because they permit custom administrative, accounting, or security programs to run as part of the login and logout procedures. For example, your modified console definition in /etc/ttys
might look similar to the following:
console "/System/Library/CoreServices/loginwindow.app/Contents/ |
MacOS/loginwindow -PowerOffDisabled YES |
-LoginHook /Users/Administrator/Scripts/mailLoginToAdmin" |
vt100 on secure onoption="/usr/libexec/getty std.9600" |
You should avoid using this technique to run your script in Mac OS X v10.4 and later. Instead, run your script using the defaults
tool, as described in “Installing Scripts Using Defaults.”
In Mac OS X v10.3, a mechanism similar to launchd
was introduced to allow the launching of programs either at system startup or on a per-user basis. The process involved placing a specially formatted property list file in either the /etc/mach_init.d
or the /etc/mach_init_per_user.d
directory.
Important: The use of bootstrap daemons is deprecated and should be avoided entirely. Launching of daemons through this process is currently limited to some Apple-specific programs and may be removed or eliminated in a future release of Mac OS X. If you need to launch daemons, use launchd
. If you need to launch daemons on versions of Mac OS X prior to 10.4, use a startup item.
In Mac OS X v10.4, launchd
was added. This is the preferred means of adding background agents on a per-user basis. These are described in more detail in “The launchd Startup Process.”
Last updated: 2008-11-19