OSX Paths, X11 and paths.d

part rant, part fix to an obnoxious bug: "1/bin"

If you’re working with a renderer from the command line, you’ll often need the location of that renderer in the path, so you can call it easily (without always needing the full path). On OSX, there is a folder paths.d under /etc, where you can place text files that will contain paths to be appended to $PATH in terminal sessions:

/etc/paths.d/Nuke6.3v8 contents:

/Applications/Nuke6.3v8/Nuke6.3v8.app/Contents/MacOS

This morning I was attempting to add some other versions to the path (7.0v1, 7.0v6) and I was running into some ridiculous errors. When I added another file:

/etc/paths.d/Nuke7.0v1 contents:

/Applications/Nuke7.0v1/Nuke7.0v1.app/Contents/MacOS
what I got in my path was instead
/Applications/Nuke7.0v1/Nuke7.0v1.app/Contents/MacOS1/bin

Why? I have no idea. I tried different file names, different text encoding types, etc and was always getting that extra text on the end. I noticed that I had one other file in my paths.d, from the installation of the osx developer tools: 50-X11. When I removed that file, everything worked! However, I want to keep that in my path (not sure what apps might be there), so I renamed it to x11 and now that extra text is gone.

I hope this helps someone else in the same situation. I don’t understand what macintosh is doing half the time, and this is that half.

Leave a Reply

Your email address will not be published. Required fields are marked *

Post Navigation