Linux – Start script on logon

./bla.sh

Here, the command is ./bla.sh. This makes the shell look for an executable named bla.sh in the current directory, then ask the kernel to run it as a normal program, in a separate process from the shell. (It doesn't matter if bla.sh is a bash script, a perl or python one, or a compiled binary.)

. bla.sh

Here, the command is . (aka source), a built-in command of your shell. It makes the shell look for a file named bla.sh in the system path ($PATH) and interpret the contents as if they were typed by you; all this is done in the same process as the shell itself (and therefore can affect the shell's internal state).

This of course only works when bla.sh contains commands for the bash shell (if that's the one you are currently using), it won't work for perl scripts or anything else.

(This is explained in help . and help source too.)

As . and ./ are completely different things (a command vs part of a path), they can be combined, of course – using . ./bla.sh would "source" a file bla.sh in the current directory.

Usually it is best to use the ./bla.sh method. Only ~/.bashrc, ~/.profile and such files are usually sourced, because they are supposed to modify the current environment.

If you have a ~/.MacOSX/environment.plist file, check it to see if it provides a default PATH value.

If it is in XML format (plists can be in many formats), you can edit with any text editor. Check it with plutil -lint ~/.MacOSX/environment.plist if you edit it by hand.

Or, you can use commands like defaults or PlistBuddy to make controlled modifications to XML or binary format plist files.

You can always set your own PATH in any of your shell's initialization files.

Put something like the following in your of your shell's startup files (.bashrc, or .bash_profile/.bash_login/.profile):

PATH=/usr/bin:/bin:/usr/sbin:/sbin
export PATH

# add custom, local installations to PATH
PATH=/usr/local/bin:/usr/local/sbin:"$PATH"

# add MacPorts to PATH
PATH=/opt/local/bin:/opt/local/sbin:"$PATH"

That will override whatever default PATH is set when the shell starts (the first PATH= does not use $PATH, so it will always start out with only whatever you give it).

Only one of the ‘login’ files will ever be used (the first one that exists and is readable of ~/.bash_profile, ~/.bash_login, and ~/.profile will be used). .profile is for backwards compatibility with other shells—if you use it, be sure to keep it free of syntax that is specific to bash. If you go with .bash_login or .bash_profile (they are functionally equivalent except for the names), then use a line like [[ -e ~/.bashrc -a -r ~/.bashrc ]] && source ~/.bashrc ]] near the top so that login shells will also get the customizations made in your .bashrc.

If you want all instances of bash to have the same PATH, then use .bashrc. If you often find yourself interactively modifying a single shell's PATH from the command line and want to use that modified PATH in subshells (a cases that is probably not terribly common), then you should put the statements in one of the ‘login’ files instead. Pick only one of the login files and use it.