/etc/paths vs /etc/paths.d

Question

Level 1

24 points

/etc/paths vs /etc/paths.d

I am curious what the purpose of the directory /etc/paths.d is. My path looks like this, first four set on /etc/paths, the last one on /etc/paths.d/50-X11

echo $PATH

/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

This is all done by Apple (Lion).

I am asking because I need to move /usr/loca/bin ahead of /usr/bin, which works fine if I edit /etc/paths. Adding to /etc/paths.d would not work for me as it seems entries in paths.d come after those in paths.

My question is which is the safest & most robust way to add to the path, systemwide (not just a .profile, etc in my home directory). I plan to start installing lots of 3rd party software and I do not want to let them touch /etc/paths.

Thank you

Posted on Jan 20, 2014 3:21 PM

Reply

Answer 1

Jan 20, 2014 6:46 PM in response to unixnerd09

One other thing putting /usr/local/bin in front of /usr/bin is a huge security hole, but I suppose you are already aware of that.

Reply

Answer 2

Tony T1

Level 6

10,247 points

Jan 20, 2014 4:13 PM in response to unixnerd09

see: man path_helper

DESCRIPTION

The path_helper utility reads the contents of the files in the directo-

ries /etc/paths.d and /etc/manpaths.d and appends their contents to the

PATH and MANPATH environment variables respectively. (The MANPATH envi-

ronment variable will not be modified unless it is already set in the

environment.)

Files in these directories should contain one path element per line.

Prior to reading these directories, default PATH and MANPATH values are

obtained from the files /etc/paths and /etc/manpaths respectively.

Reply

Answer 3

etresoft

Level 9

56,022 points

Jan 20, 2014 5:27 PM in response to unixnerd09

unixnerd09 wrote:

I plan to start installing lots of 3rd party software and I do not want to let them touch /etc/paths.

Such as? It is unlikely that any of them would use /etc/paths.d. A ports package like homebrew might, but I am not familiar with them.

You would only need /usr/local to be in front of /usr if you are trying to override something. What are you trying to override?

Reply

Answer 4

unixnerd09 Author

Level 1

24 points

Jan 20, 2014 6:17 PM in response to Tony T1

Thank you.

That's the confirmation that what I see (paths.d after paths) is the intended behavior.

Reply

Answer 5

unixnerd09 Author

Level 1

24 points

Jan 20, 2014 6:47 PM in response to etresoft

Yes, I was able to override the emacs that came with OS X with the one I installed in /usr/local by simply editing /etc/paths. I had to do this because the build did not touch /etc/paths, which is a good thing.

I plan to experiment homebrew, macports and such, see which one fits my needs.

I guess I should rephrase my question. I would like to know what is usually done so that I know in advance where to look if a package breaks my path.

For example, I just installed a Python distribution (Canopy) and it put in ~/.profile the line "source path-to-some-script", where the script does something complicated to prepend the Canopy path the existing $PATH.

I am used to simply explicitly prepending or appending paths to $PATH in a .profile or .bashrc, .cshrc, etc file, and all this seems a bit unusual.

Thank you

Reply

Answer 6

unixnerd09 Author

Level 1

24 points

Jan 20, 2014 7:06 PM in response to Frank Caggiano

Thank you, I must confess I did not think of that, but I can now see how this can be dangerous. Since the only purpose was to use my newly installed emacs in /usr/local/bin, I guess I will simply rename the one that came with Mac OS in /usr/bin, and revert to the original /usr/bin first.

Reply

Answer 7

BobHarris

Level 9

56,681 points

Jan 21, 2014 6:14 AM in response to unixnerd09

Why not establish your desired PATH in your .bash_profile when you start a Terminal session?

Besides the security implications, there are also Mac OS X daemons and scripts that may fail if their PATH is not the expected default PATH.

Now if you ONLY put emacs in /usr/local/bin, then chances are nothing will break, but if you start putting all kinds of open source stuff in /usr/local/bin, then the chances are you will eventually break some Mac OS X background maintenance task or daemon.

Reply

Answer 8

etresoft

Level 9

56,022 points

Jan 21, 2014 7:35 AM in response to unixnerd09

You can just use "alias" to define "emacs" point to your new version. If tools need any supporting files they probably have some environment variable to define where they live. Having multiple versions of software is pretty common in the UNIX world.

I suggest keeping the system path the way it is. There are a whole lot of gotchyas that could get you later on down the road. Things will work initially, but if you need to make any changes (like upgrading the OS or a tool), things could get messy.

Reply

Answer 9

unixnerd09 Author

Level 1

24 points

Jan 21, 2014 5:34 PM in response to BobHarris

I was hoping to do something user and shell independent. But I guess simpler is better so I will go with setting the path in ~/.bash_profile or just an alias, like etresoft suggested.

Thank you both,

Reply

Answer 10

Jan 21, 2014 6:00 PM in response to unixnerd09

You could edit /etc/profile and add the alias there then all users will get it.

Reply

Answer 11

unixnerd09 Author

Level 1

24 points

Jan 21, 2014 7:37 PM in response to Frank Caggiano

Thanks, that works. That's fine for individual programs though. If I want to switch back and foth between, for example, different Python distributions, I still need to go with bash_profile...

Reply

Answer 12

etresoft

Level 9

56,022 points

Jan 22, 2014 6:47 AM in response to unixnerd09

The culture of coding is curious. I have three versions of Python on my system and there are apparently 4 newer versions available, not counting the current development branch. That's just crazy.

Reply