For the sake of clarity, I will refer to this solution as the static solution, the second solution as the dynamic solution, and finally this one as the launch agent solution. I am going to compare the static and dynamic solution with the launch agent one, respectively.
The static solution involves the editing of
/etc/launchd.conf. This has the advantage, as with the launch agent solution, that the variables are set right at the login. Disadvantages are that
- the variables are defined for all users. The launch agent solution lets each user decide for himself. If one wants to define variables for all users with the launch agent solution, the shell script can be amended with a loop (and another file),
- the definition of the variables in
/etc/launchd.confdoes not allow for things like variable substitution and such stuff (at least that is my guess, maybe it is feasible),
- obviously, you need access to
/etc/launchd.confto pull the static solution off, with the other one you can put all files at accessible places, e.g. the launch agent in
- the variables are not available immediately after editing the file, as with the launch agent solution (but see below).
The dynamic solution is similar to the launch agent solution. Its disadvantage is that the variables are not available right after login, you first need to (re-)define them. To combine the dynamic solution with the other, imagine you wanted to set the variable
FOO to the content of the variable
BAR. You would fire up a shell, say the bash, and type
launchctl setenv FOO "$BAR" echo 'setenv FOO $BAR' >> ~/.conf.launchd
FOO would be available in all applications started after this definition, and would also be defined right after the next login.