Adam Jordens@littlesquare:~/

1. Guillaume Laforge

   Jan 25th, 2008 at 12:54 am

   Interesting tip.
   I’d be curious to know if there’s a possibility to easily switch some environment variables. Let’s say today I want to use Java 1.4 and Groovy 1.0, and that later one, working on another project, I want to use Java 5 and Groovy 1.5.
   How shall I do?

2. jpc

   Feb 28th, 2008 at 3:24 pm

   Adam Jordens: The only problem with your solution is that there is little improvement over hardcoded paths in /etc/profile if you hardcode the environment variables instead. The clean Leopard profile looks like this:
   # >>> START
   # System-wide .profile for sh(1)

   if [ -x /usr/libexec/path_helper ]; then
   eval `/usr/libexec/path_helper -s`
   fi

   if [ "${BASH-no}" != "no" ]; then
   [ -r /etc/bashrc ] && . /etc/bashrc
   fi
   # <<< END

   Similar stuff can be found in csh.login and .zprofile (I can post them if anyone is interested.

   Guillaume Laforge: I would make a Java symlink pointing to Java-1.5 somewhere and only add Java/bin to the PATH (so when you switch the symlink you will run new binaries).

3. ajordens

   Mar 3rd, 2008 at 12:03 am

   I agree that it’s not that much of a difference but you will only be hard-coding the paths in one location.

   Personally (and prior to using paths.d in Leopard) I’d just do my all my exports and PATH setup in the /etc/profile or .bash_profile directly.

   For a lot of frameworks, you will need to define a FRAMEWORK_HOME environment variable in addition to simply including it on the path. In these situations, I’d argue there’s a slight benefit.

   And I agree w/ your suggestion to Guillaume, that’s a pretty standard approach to separating your VMs and is something Apple and the various Linux distros having been doing for awhile (/etc/alternatives/java, etc.).

4. Jürgen

   Apr 7th, 2008 at 11:16 am

   Thanks for your post! I helped me a lot.

5. Stephen

   Apr 22nd, 2008 at 4:29 pm

   I used a vanilla (unmodified) /etc/profile as it is read only for me, and just added a nice little test file called cdrtools to /etc/paths.d and it worked like a charm! All I had to do was restart my terminal app (opening a new tab would have done the trick as well I assume.

   Thanks!

6. Stephen

   Apr 22nd, 2008 at 4:35 pm

   Nevermind that previous comment…like a previous poster mentioned path helper is automatically initialized in the /etc/profile

7. Lorin Rivers

   Jun 24th, 2008 at 12:11 pm

   What’s wacky about this whole scheme is that you have no control over load order, so if you (for example) use MacPorts, how do make /opt/local/bin be the first part of your $PATH?

8. Kamil Kisiel

   Jul 14th, 2008 at 1:37 pm

   Lorin: You can add paths to /etc/paths instead, if you care about the order.

9. Renato

   Aug 2nd, 2008 at 12:35 pm

   I had also the problem of wanting /usr/local/bin be first in the path before the defaults. My issue was that I wanted to override a default install of svn and use a newer installed in /usr/local/bin. But the problem is the same as for you.

   I played around w/ “/etc/path.d” and edited “/etc/paths” itself adding always “/usr/local/bin/” on top but it would always get listed after the defaults.

   I looked at “/etc/paths” and found the following entries:
   /usr/bin
   /bin
   /usr/sbin
   /sbin
   /usr/local/bin

   I had in “/etc/paths.d/” only the file “X11″ which contained one line: “/usr/X11/bin/”
   doing a “set” or “echo $PATH” from the command line would return:
   PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

   So it was clear (also explained in the man page for path_helper) that the content of of the paths.d directory would always be appended to what was found in “paths” itself.

   I placed “/usr/local/bin” at top of paths but the order didn’t change. I logged out and back in and even rebooted to make sure there is nothing else causing this behavior but it always remained in the same order.

   If I removed “/usr/local/bin” it was gone from the path but the rest stayed as is.
   I had the suspicion that the content of “/etc/paths” didn’t really matter for the default entries of “/usr/bin:/bin:/usr/sbin:/sbin” and took them completely out of “/etc/paths” and logged into another shell to prove it. And sure enough, even w/o the entries the path variable was the same.
   Therefore here is the order it apparently uses when it calls “path_helper” from /etc/profile at login:
   1) System defaults
   2) /etc/paths content aside system defaults
   3) /etc/paths.d/ content
   Apple wanted apparently to play save and not allow users to override system defaults and evtl. cripple the system.

   I finally solved the problem by adding
   export PATH=/usr/local/bin/:$PATH;

   before the path_helper call in /etc/profile:
   if [ -x /usr/libexec/path_helper ]; then
   eval `/usr/libexec/path_helper -s`
   fi

   Now “/usr/local/bin” is searched first

Leave a Comment

trackback address