On Fri, Jan 21, 2011 at 1:40 PM, Gustaf Olsson <gustaf.olsson.lnu.se> wrote:
> Thank you SO much Ben!
>
> By running:
>
> cd /usr/local/amber11/test && ./test_amber_serial.sh
>
> as superuser, the tests begun and are rolling as we "speak". What I cannot
> wrap my head around is how echo and evn | grep..... both returns all the
> right info, but it still does not work?
>
This is explained by my previous post. The reason this is working *now* is
because you are spawning a root shell from another root shell, so it
inherits all environment variables. This is not true when you launch a root
shell from a non-root shell (for security purposes, I'm sure).
It's dangerous, however, to be playing around in your system as root,
especially when you're *trusting* that a 3rd-party package (that you didn't
write) isn't going to do anything malicious (either by accident or
intentionally). Who knows what test accidentally removes a file from
../../../bin instead of ../../bin (thereby potentially removing stuff from
either /usr/local/bin or even /usr/bin instead of /usr/local/amber11/bin as
it was supposed to!).
My advice, adapted (or rather taken directly) from Lachele (another
contributor to this list) is to give some default installation-user
ownership of directories you intend to install software in (i.e. /usr/local
or /opt/local if you're going to be using MacPorts, or /sw if you use Fink),
and run all installation *without* using sudo or sudo -s.
>
> I'm going to be forced to try running:
>
> cd $AMBERHOME/test && ./test_amber_serial.sh
>
> Just to se if that can circumvent this problem. I just cannot see the
> problem, cd $AMBERHOME/test brings me to the exact same location as cd
> /usr/local/amber11/test
> Login shell in mac is by default bash, it says so on the window bar at the
> top. But as far as I have been able to figure, Mac has its own version of
> bash since running "bash" changes the prompt from VCN736:~ guolaa$ to
> bash-3.2$.
>
When you type "bash", it executes that program, dropping you into a *new*
bash shell session. You will see that it inherits all environment variables
from your previous shell session (which is just another instance of bash).
However, you can export new environment variables and the like, but as soon
as you exit, it will drop you back to the parent shell session (the original
one you typed bash from) and all changes you made in the *new* session will
have died when you quit that shell.
It is useful to understand the scope of local and environment variables
within the shell context. I will not go into a treatise here.
>
> Based on this I have made some assumptions, see under root (/etc) there are
> two "global" profile files, one called profile and one called bashrc. Of
> these two, profile has priority.
>
This is true. But typically, if a .profile file exists, it will source
~/.bashrc either at the beginning or the end.
>
> In you user account ($HOME), you can just create .profile, .bashrc, .cshrc,
> and so on... These are read at terminal startup and at shell-change, but
> .profile has priority in bash over .bashrc and is read at startup of
> terminal. So for all my software I set environment and PATH variables in
> .profile in my $HOME. It has always worked perfectly, except for tests and
> bugfix with AMBER.
>
Again, because you are launching a root shell, which has higher priority
than a normal user shell, and as such will not inherit environment variables
and such declared in the originating shell. To exemplify this, try the
following:
export TEST='listen to me'
echo $TEST
sudo -s
echo $TEST
exit
echo $TEST
You will see that the first and the third return "listen to me", but the
second does not.
I hope this helps clarify things.
All the best,
Jason
> But thanks to you I can finally gets the job done
>
> Best regards
> // Gustaf
>
> On Jan 21, 2011, at 7:18 PM, Ben Roberts wrote:
>
> > Hi Gustaf,
> >
> > On 21/1/2011, at 1:08 p.m., Gustaf Olsson wrote:
> >
> >> Thanks for you input Ben, sadly; no such luck.
> >>
> >> Both the echo and env grep presents AMBERHOME as set correctly, but test
> still fails!
> >>
> >> /usr/local/amber11
> >>
> /usr/local/amber11/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
> >> VCN736:~ guolaa$ cd /usr/local/amber11/test/
> >> VCN736:test guolaa$ env | grep PATH
> >>
> PATH=/usr/local/packmol:/usr/local/amber11/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
> >> VCN736:test guolaa$ env | grep AMBERHOME
> >> AMBERHOME=/usr/local/amber11
> >> VCN736:test guolaa$ sudo make test
> >> (find . -name '*.dif' -o -name 'profile_mpi' | \
> >> while read dif ;\
> >> do \
> >> rm -f $dif ;\
> >> done ;\
> >> )
> >> rm -f TEST_FAILURES.diff
> >> Error: AMBERHOME should be defined or else some tests will fail !
> >> make: *** [is_amberhome_defined] Error 2
> >> VCN736:test guolaa$
> >>
> >> Best regards Gustaf
> >
> > If you would, try running "cd /usr/local/amber11/test &&
> ./test_amber_serial.sh". That will test $AMBERHOME first thing, and if the
> latter is not defined it will fail.
> >
> > Also, where exactly are you setting $AMBERHOME? It may be that the test
> is starting up as a non-login shell. If it's doing that, setting AMBERHOME
> in bash_profile or its equivalent may be problematic; bash_profile files are
> ignored for non-login shells (I think).
> >
> > --
> > For greater security, I support S/MIME encryption.
> >
> >
> > _______________________________________________
> > AMBER mailing list
> > AMBER.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
352-392-4032
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Jan 21 2011 - 11:00:03 PST
