There are several places where you can set environment variables.
~/.profile: use this for variables you want to set in all programs launched from the terminal (note that, unlike on Linux, all shells opened in Terminal.app are login shells).
~/.bashrc: this is invoked for shells which are not login shells. Use this for aliases and other things which need to be redefined in subshells, not for environment variables that are inherited.
/etc/profile: this is loaded before ~/.profile, but is otherwise equivalent. Use it when you want the variable to apply to terminal programs launched by all users on the machine (assuming they use bash).
~/.MacOSX/environment.plist: this is read by loginwindow on login. It applies to all applications, including GUI ones, except those launched by Spotlight in 10.5 (not 10.6). It requires you to logout and login again for changes to take effect. This file is no longer supported as of OS X 10.8.
- your user's
launchd instance: this applies to all programs launched by the user, GUI and CLI. You can apply changes at any time by using the
setenv command in
launchctl. In theory, you should be able to put
setenv commands in
launchd would read them automatically when the user logs in, but in practice support for this file was never implemented. Instead, you can use another mechanism to execute a script at login, and have that script call
launchctl to set up the
/etc/launchd.conf: this is read by launchd when the system starts up and when a user logs in. They affect every single process on the system, because launchd is the root process. To apply changes to the running root launchd you can pipe the commands into
The fundamental things to understand are:
- environment variables are inherited by a process's children at the time they are forked.
- the root process is a launchd instance, and there is also a separate launchd instance per user session.
- launchd allows you to change its current environment variables using
launchctl; the updated variables are then inherited by all new processes it forks from then on.
Example of setting an environment variable with launchd:
echo setenv REPLACE_WITH_VAR REPLACE_WITH_VALUE | launchctl
Now, launch your GUI app that uses the variable, and voila!
To work around the fact that
~/.launchd.conf does not work, you can put the following script in
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<string>launchctl < ~/.launchd.conf</string>
Then you can put
setenv REPLACE_WITH_VAR REPLACE_WITH_VALUE inside
~/.launchd.conf, and it will be executed at each login.
Note that, when piping a command list into launchctl in this fashion, you will not be able to set environment variables with values containing spaces. If you need to do so, you can call launchctl as follows:
launchctl setenv MYVARIABLE "QUOTE THE STRING".
Also, note that other programs that run at login may execute before the launchagent, and thus may not see the environment variables it sets.
System.getenv() is platform-independent by itself. Using your above example, you can most certainly write
String value = System.getenv("MY_ENV_VAR")
and it will work on both Linux and Windows. No reason to wrap this into java system property. That said, the "platform-dependent" part of
getenv() lies in the fact that different operating systems use different environment variables, like PATH on windows vs path on Linux. But as long as you're using your own variables and name them consistently (always uppercase, for example), you'll be fine.
In Delphi, the special system folder path constants are defined in ShlObj.DCU, and are referenced in the form of CSIDL_ followed by a symbolic name. Example:
Here's a quick function that will return the appropriate special folder path when given the symbolic name. Make sure you include the SHLOBJ.DCU unit in your USES statement, and use the following:
For reference, the constants are as follows: