[tlu] PATH not propagated to *-sys scripts (Yosemite)

Jeffrey Goldberg jeffrey at goldmark.org
Thu Jul 10 18:37:22 CEST 2014


I am not certain whether this is an issue in tlu (Version 1.17 (1.17)) or in MacTeX installation on OS X 10.10 (developer preview),

I will present log files and samples below that illustrate my description here.

Summary: /usr/texbin appears to be in my path and remains in the PATH when I use sudo. When I run fmutil-sys and updmap-sys from the command-line they work without error. But when they are called via tlu, they fail as if /usr/texbin is not in the path.

According to tlu logs, tlu is correctly picking up /usr/texbin in PATH.

2014-07-10 00:52:10 +0000 Notice +[TLMEnvironment updatePathEnvironment][62979]	Using PATH = "(
    "/usr/local/bin",
    "/usr/bin",
    "/bin",
    "/usr/sbin",
    "/sbin",
    "/usr/texbin"
)”

I have manually added /usr/textbin to the PATH through /etc/paths.d/TeX

$ cat /etc/paths.d/TeX 
/usr/texbin

Things like

  sudo fmtutil-sys --byfmt latex

succeed without error. 

But when it is called from tlu, I see this in the logs.

2014-07-10 00:54:22 +0000 Warning tlu_ipctask[63295]	running fmtutil-sys --no-error-if-no-engine=luajittex --byfmt latex ...
2014-07-10 00:54:22 +0000 Warning tlu_ipctask[63295]	
2014-07-10 00:54:22 +0000 Warning tlu_ipctask[63295]	fmtutil-sys --no-error-if-no-engine=luajittex --byfmt latex failed (status 127), output:
2014-07-10 00:54:22 +0000 Warning tlu_ipctask[63295]	/usr/texbin/fmtutil-sys: line 22: kpsewhich: command not found
2014-07-10 00:54:22 +0000 Warning tlu_ipctask[63295]	/usr/texbin/fmtutil-sys: line 23: kpsewhich: command not found
2014-07-10 00:54:22 +0000 Warning tlu_ipctask[63295]	/usr/texbin/fmtutil-sys: line 29: exec: fmtutil: not found

which looks like the PATH used within the fmtutil-sys script does not include /usr/texbin .

I have to confess that I don’t fully understand how PATH and other environment variables are propagated under sudo versus OS X privilege escalation. I also haven’t checked the tlu source to see if it is using the deprecated AuthorizationExecuteWithPrivileges approach or the 10.7 and greater XPC approach.

One thing that might be useful is to log the environment after privilege escalation.

Any help at sorting this out and also learning whether this is just a problem for me would be appreciated.

Cheers,

-j








More information about the tlu mailing list