MrGibbage wrote: > When I test SA, I log into a bash shell. I set my environment > variables in .bash_profile (loading changes with the 'source' > command).
Login bash shells source the .bash_profile. But scripts and system daemons such as spamd do not. So you are right that there is potential for differences. > What is the best way to be aware of this, > ... > How can I find out exactly what environment my real mail is being > processed under? Use the 'id' command to see your user identity. Use 'env' to print the environment variables. For example I will often put a little test snippet in a script that does something like this: Change original script from this: #!/bin/sh ...do.something... To this debug modification: #!/bin/sh (id;env) > /tmp/$(id -u).debug.out ...do.something... Then I cause it to be run and then go look in /tmp/$(id -u).debug.out for the debug output and see who the script was running under and with what type of environment. Don't forget to remove the debug when you are done. Also hacking on a production system is not recommended. Best in a test system. > and how do I work around it? Find the problem first and then worry about trying to work around it. You may not have a problem at all. Or you might. And the solution depends upon what you are doing. But assuming that you want to force a clean environment for a command then you can use 'env' to run commands with a small reviewed environment. env -i PATH=/usr/local/bin:/usr/bin:/bin HOME=/root somecommand someargs Because of the -i the env command will initialize an empty environment and only the enviroment variables you specify will be set for the command when it runs. This protects the command from random things you may have stuffed into your interactive environment. > Perhaps I shouldn't be setting environment variables in > .bash_profile??? It is a good place to put interactive shell configuration such as PATH, MANPATH, LANG, EDITOR, LESS and so forth. Things that affect your interactive environment. Bob
