I think it is a "no can do" sort of problem...
First -- you wouldn't want to source that script because of the exit 0 at the end.
Second, no unix child process can directly change the environment of the parent. Otherwise all sorts of crazy things would be possible.
Could you add something to their environment with the default profile or bashrc files, or could you write a wrapper for whatever program it is they are trying to run?
Allow me to elaborate on the "wrapper" concept.
Let's say you want to run the program snoopy with either PROD or DEV in environment variable "OPTIONS" depending on if you want production or development. IF it isn't set, let's say snoopy does something zany like wipe out the database for production and development...
rename "snoopy" to snoopy.bin (or .snoopy.bin)
then put a script in that same location named "snoopy" that contains this:
#!/bin/sh
export OPTIONS
case "$OPTIONS"
in
PROD) ;;
DEV) ;;
*) OPTIONS=DEV ;;
esac
#the binary is actually named snoopy.bin
exec "$0.bin" "$@"
If you don't want to muck with the actual file, put this script somewhere in the filesystem that will be ahead of the actual snoopy program in the user's PATH and have a full path to the binary in the script's exec statement...
Try putting /bin/bash in front of your command. You can't use relative paths because there is no environment to keep track of them. If you run everything in a bash-shell, bash will keep track of these things for you. Same goes for crontab
Best Answer
The scripts at/etc/profile.d/*are executed in their own shells rather than sourced so the environment variables they set are not available anyway.What variables do you need? Can you make use of/etc/environment? Can you write the variables into a file in avar=valueformat from the appropriate scripts and source that file in yourrc.localscripts?This is from the Bash man page. You may find it helpful.
The Bourne shell similarly uses the
ENVvariable.