Configure /etc/paths

There are inherent dangers in just about everything you do on your machine... it's partly a matter of trust and risk management.

Theoretically, since you've given preference to /usr/local/bin over /usr/bin then any binary in /usr/local/bin is going to have priority. If some malicious software gets installed in /usr/local/bin then you could be in trouble. This includes all the standard build tools (/usr/bin/make, /usr/bin/gcc, /usr/bin/autoconf, any of which could compromise building applications on your machine) and even things like /usr/bin/ssh which could compromise logging into other machines on your network.

Add to that the fact your machine is then configured radically differently from any other machine, and you might not remember that when you switch machines, upgrade, etc.

So, in general, I'd agree with your friend - this is a bad idea, although not fatal. Far better, in my opinion to specify the path to /usr/local/bin/git when you need it, or symlink /usr/local/bin/git to /usr/bin/git if that's your specific need, or even setup a shell alias. Any of these options would let you get what you want (a lazy way to launch git) without potential risks.

By making this change for every process, you run the risk that some maintenance script written for a specific utility gets your substituted utility and fails.

In the same vane, no one should replace a standard utility in it original location with a replacement, again as a maintenance script could fail. Using, as you are, /usr/local/bin is a better idea, or similar location for utilities you want to add.

Generally speaking it is better to modify your own personal $HOME/.bash_profile, than it is to make a global change.

If you need the PATH changed for some GUI app, then you can create a $HOME/.MacOSX/environment.plist file. RCEnvironment from rubicode can be used to create and maintain .MacOSX/environment.plist files.

<http://www.rubicode.com/Software/>

With respect to security, /usr/local/bin before /bin, /usr/bin, /sbin, /usr/sbin is only a risk if you all anyone to add commands and utilities to the /usr/local/bin directory, as those programs could then be a Trojan.

And what about ~/.profile with PATH=/usr/local/bin;$PATH ?

nothing, except you syntax is wrong (should be a : and not a ; ). Also you need an 'export' command. If your syntax was put into place, the ONLY command that would be accessible would be those in /usr/local/bin, and all the standard commands would be unseen by the shell.

export PATH=/usr/local/bin:$PATH

My suggestion (above) was to put this into $HOME/.bash_profile as it is the bash shell specific, however, as long as you do not have a .bash_profile, then bash will read .bash_login, and if you do not have a .bash_login, bash will read .profile

Camelot wrote:
or symlink /usr/local/bin/git to /usr/bin/git

I think this is a bad idea (maybe not so much for git, but in general). The Mac user is not the only one that uses programs, commands, and utilities in the standard directories, and if someone replaces the original program with a substitute, some maintenance task or application that uses that program, command or utility may fail because the substitute does not behave as expected.

Putting stuff in /usr/local/bin (/sw/bin, /opt/local/bin, ...) and then changing your personal PATH is a better idea as that should not affect maintenance tasks.

If a GUI program uses some standard program and the user changed .MacOSX/environment.plist the app could still get burned.

Another consideration is ~/.profile can be read by bash, ksh, or zsh while ~/.bash_profile is specific to bash and the first and only config file read at startup (if it exists).

Well, the current version of zsh will only read .profile if you set emulate sh. With zsh .zshenv will be read by login and interactive shells or .zprofile will be read by login shells.