We're setting up an SGE cluster with CentOS 6. My sysadmin is installing applications that are not installed via RPM (i.e. via other means like make install) should go in a non-standard directory, in this case something like /share/apps/install/bin/. The path for this is currently added to most sessions (login, qlogin, etc) via /share/apps/etc/environment.sh which is called by /etc/bashrc. environment.sh also appends some stuff to the PERL5LIB.

The problem that I'm running into is that the /share/apps/install/bin is not added to some instances, e.g. things called out of a crontab.

I know I can manually and explicitly set PATH=/bin:/usr/bin:/blah/blah:... within my personal crontab or within any given script or crontab entry, but what I'm hoping is that there's a setting somewhere outside of /etc/profile or /etc/bashrc that would put the non-standard .../bin directory into all PATHs for all users.

  • Isn't /usr/local used for non-RPM things?
    – kurtm
    Commented Oct 10, 2013 at 20:02
  • Probably, but my admin has decided to put things in the aforementioned directory. Besides, the default path in things called out of cron seems to be /usr/bin:/bin
    – Aphoid
    Commented Oct 10, 2013 at 20:15
  • Yes. Just seems like a lot of effort to go to since you'll have to reconfigure everything you compile since they tend to default to /usr/local. (Most distributions change it to not go in /usr/local)
    – kurtm
    Commented Oct 10, 2013 at 20:18

3 Answers 3


Add a file with the value you want the PATH to have in /etc/profile.d. These files are setup to be sourced by shells such as Bash, Csh Zsh, or tcsh.


We needed to have the following value added to our PATH.


So we created a file, /etc/profile.d/ourstuff.sh, with the following line in it:

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

Files with the extension .sh are sourced by shells such as Bash and Zsh. Files with the extension .csh are sourced by Csh and tcsh.

EDIT #1 - Follow-up

OP asked the following follow-up question.

Yes, but what about cron jobs? Is there a way to get the path even there? cron doesn't seem to call /etc/profile or /etc/bashrc.

To which I responded:

Correct it doesn't nor will it. You need to set the SHELL=/bin/bash in cron to override the default shell (typically /bin/sh). Also you can set the this for user crons, BASH_ENV="$HOME/.bashrc", and this for system crons, BASH_ENV="/root/.bashrc". Would be one way around this.

I would highly suggest that you not do this. Let the scripts that need a specific environment, set it up themselves. Don't try to solve every problem at the global level!

  • Yes, but what about cron jobs? Is there a way to get the path even there? cron doesn't seem to call /etc/profile or /etc/bashrc.
    – Aphoid
    Commented Oct 10, 2013 at 20:16
  • 1
    In fact, relying on the path for things like cron which should be executing the same processes in a consistent matter is a generally bad practice. By doing that if you have accidentally lessened the permissions on any file which could get sourced in before execution I can now override your binaries and (potentially) have arbitrary code execution as root. Always use full paths if possible. Commented Oct 10, 2013 at 20:45

You can put environment variable definitions in /etc/environment (assuming that your system loads pam_env for all services, which should be the default on all modern non-embedded Linux systems).

Note that you can only put static environment variable definitions, of the form VARIABLE=VALUE or VARIABLE="VALUE", with one definition per line. You can't have arbitrary shell commands, you can't refer to the value of another variable by writing FOO=hello+$BAR (that puts a literal $ in the value of FOO), etc. As long as you stick to simple assignments like PATH=/usr/local/bin:/usr/bin:/bin:/share/apps/install/bin, you'll be ok (note that you can't use the user's home directory there: the value has to be the same for all users).


What we ended up doing was a multi-pronged solution to avoid any path issues. Depending on the use case, we used one or more of the following:

  • Used absolute paths to the binaries installed in non-standard places instead of expecting the binary to be on the path. This was used for tools that have few, if any, non-standard external dependencies and/or work in isolation.
  • Created and used a wrapper script for a tool that set up the environment as needed; manually setting the PATH=... within that script and/or running source $HOME/.bashrc as appropriate. This was used for tools that needed other tools, but were otherwise able to run on our cluster.
  • Created a container (Docker in our case) including the binaries and a more complex setup. This was used for tools that require an environment significantly different from our standard cluster setup.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .