MacOS – Setting environment variables (TEXINPUTS) in El Capitan

latexlaunchdmacos

I am a user of TeXShop, an application launched from the Launchpad. Everything works great except that in order to get full functionality, I need to set the TEXINPUTS environment variable. (To be precise, the variable must be set for certain processes launched by TexShop. It is normally inherited from the parent process.)

Until I upgraded to El Capitan, I could do this by calling launchctl setenv TEXINPUTS some-appropriate-value. Unfortunately, this has stopped working after upgrading. The command appears to succeed, and querying with launchctl getenv TEXINPUTS shows me the value I set, but it is not passed to applications I launch from the GUI. (I have confirmed this by launching a Terminal and checking the environment.)

The launchctl manual page has this to say about the config system command:

path: Sets the PATH environment variable for all services within the target domain to
the string value. […] Note that if a service specifies its
own PATH, the service-specific environment variable will take precedence.

NOTE: This facility cannot be used to set general environment variables for all
services within the domain. It is intentionally scoped to the PATH environment
variable and nothing else for security reasons.

So it seems that Apple (a) does not want to pass my environment settings to applications willy-nilly, may have a way to customize the environment of specific "services". Does anyone know how I can get my editor to "see" the TEXINPUTS variable?

PS. Almost all related questions I've seen are about setting PATH. Solutions specific to setting the system path are not going to help here.

Best Answer

The problem is well known and is due to Apple - the /usr folder cannot be anymore written. The solution is to add a link to this location: /Library/TeX/texbin - depending also on your TeX version, see more info in this link: https://tug.org/mactex/elcapitan.html

Related Solutions

Force launchd to re-read environment variables

There is no way to do this, "launchd" is the master process, the equivalent of "init" in other unix systems, the only way in any other daemon would be to perform some sort of kill -HUP to reload config files etc, but this operation is not permitted on launchd. If you look it up in the process table it is the number 1 process, every other process that is currently running is in some way a child of it, so a reboot is the only way to achieve this. You may have further luck in setting those environment variables in another area that is more inclined to allow restarts.

    Dans-iMac:etc stuffe$ ps -ef | grep launchd | grep -v grep
    0     1     0   0  9:40am ??         0:09.47 /sbin/launchd
   65    18     1   0  9:40am ??         1:53.64 /usr/sbin/mDNSResponder -launchd
  213    73     1   0  9:41am ??         0:02.55 /System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/Resources/usbmuxd -launchd
    0    85     1   0  9:41am ??         0:00.08 /System/Library/CoreServices/ODSAgent.app/Contents/MacOS/ODSAgent -launchd
   89   230     1   0  9:41am ??         0:00.01 /sbin/launchd
  501   238     1   0  9:41am ??         0:00.23 /sbin/launchd
  501   933   238   0 10:53am ??         0:00.01 /System/Library/CoreServices/AirPort Base Station Agent.app/Contents/MacOS/AirPort Base Station Agent -launchd -allowquit

EDIT:

Of course, missing the obvious solution that you can add the relevant variables into the config file, and then just run the commands manually in order to escape the need for a reboot, nothing that only newly start programs will take account of any changes. I found this page which explains it in more detail:

Environment variables set in launchd will be available to all programs on the system. However since $HOME/.launchd.conf is not supported, this approach is used for global environment variables only.

The /etc/launchd.conf file contains a list of commands to be run by launchctl during startup. However environment variables set in /etc/launchd.conf cannot have spaces and cannot reference other environment variables; launchctl when run in Terminal does not suffer these limitations. Do note that /etc/launchd.conf does not exist by default, so we will need to create it.

A reboot is necessary to load the contents of /etc/launchd.conf. However if you were to run the corresponding launchctlcommands in Terminal, you can alleviate the need for the reboot. Just remember that if you only do the launchctl commands, and do not put the entries in /etc/launchd.conf, it will not persist after reboot.

If you want to have a system wide environment variable that uses spaces or be dependent upon another environment variable, you can put the launchctl commands into one of the files Terminal reads. You will have to quit and relaunch Terminal to access the newly set variables.

MacOS – In Mountain Lion how to set, in one place, the PATH environment variable for all newly launched applications

After many trials with different options I conclude:

Is there a unified way to set the PATH for applications launched by different means (like shell script, Finder and Spotlight)? Well, yes and no:

No: Setting PATH in shell start up scripts (e.g. .bashrc) works only for apps launched by shells.
No: Setting PATH for the current launchd process via launchctl setenv PATH <...> does not work for me at all.
Yes: Setting PATH in /etc/launchd.conf (and restarting the system) will make the appropriate PATH visible in applications launched by Spotlight, Dock and Finder and subsequently (local) shells.
No: Remotely invoked shells do not inherit the environment. (See ...why do remote shells via ssh do NOT inherit the environment..)

Notes for set-up of shells:

For correct functioning in local shells it is important to switch off the use of /usr/libexec/path_helper, because the default paths in /etc/paths might change the order of the paths in PATH.**
To accommodate remote shells you need to re-import the launchd environment into the shell. Use something like this in your .bashrc:

# the vexatious path stuff
eval $(launchctl export)

Unfortunate consequences of the whole issue are:

No way to have these unified settings on a per user basis. (~/.launchd.conf does not work.)
No easy way to construct the PATH from different sources using techniques like home directory expansion et al.