You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by MrGibbage <sk...@pelorus.org> on 2009/07/10 15:12:12 UTC

OT--Linux environment

Just a little off topic here, but relevant.  When I test SA, I log into a
bash shell.  I set my environment variables in .bash_profile (loading
changes with the 'source' command).  Sometimes when testing, I get different
results than I do when processing real mail.  I think it is because when my
mail comes in, it is under a different environment.  What is the best way to
be aware of this, and how do I work around it?  How can I find out exactly
what environment my real mail is being processed under?  Perhaps I shouldn't
be setting environment variables in .bash_profile???
-- 
View this message in context: http://www.nabble.com/OT--Linux-environment-tp24427323p24427323.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.


Re: OT--Linux environment

Posted by Bob Proulx <bo...@proulx.com>.
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