share/spack/setup-env.sh fails when executed indirectly from a symlink

[malcook]

Hi,

I find that share/spack/setup-env.sh fails when executed indirectly from a symlink, say, from /etc/profile.d/spack-setup.sh

This is easily fixed by changing line 155 of setup-env.sh to use the readlink function:

_sp_source_file=$(readlink -f "${BASH_SOURCE[0]}")  # Bash's location of last sourced file.

Agreed?

I tested in zsh too.

I promise I will get with the pull-requests soon.

~Malcolm

[tgamblin]

@malcook: Look at e18c9e8 (Branch bugfix/setup-env). I have taken your commit and modified it slightly. The -f option to readlink isn't on BSD readlink, so I switched the script to use $(cd -P $(dirname <arg>) && pwd). If that works for you I can merge it to develop.

[malcook]

@tgamblin: huh? when i 'look' at e18c9e8 I see my pushed changed without your proposed modification. Did you forget to push, or are my git skill missing something?

I'm not up on all the diffs between linux distros. But I think gnu core-utils is probably available on all.

Also, I don't think your proposal would work anyway. Once you take the dirname you've lost the symlink.

Consider:

$ which java
/usr/bin/java
$ ls -la $(which java)
lrwxrwxrwx. 1 root root 22 Apr 17 20:50 /usr/bin/java -> /etc/alternatives/java
$ ls -la /etc/alternatives/java
lrwxrwxrwx. 1 root root 74 Apr 17 20:50 /etc/alternatives/java -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.79-2.5.5.1.el7_1.x86_64/jre/bin/java

but

$ echo $(cd -P $(dirname $(which java)) && pwd)
/usr/bin

whereas

$ echo $(readlink -f $(which java))
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.79-2.5.5.1.el7_1.x86_64/jre/bin/java

Perhaps considering this is a python project is to use python's os.path.realpath

$ python -c 'import os,sys;print os.path.realpath(sys.argv[1])' $(which java)
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.79-2.5.5.1.el7_1.x86_64/jre/bin/java

[tgamblin]

@malcook: Oops! Sorry, I probably typed that too fast. I took your commit and modified it and here's the result: 9bb1f1c (which is also the tip of bugfix/setup-env. Sorry for the mixup.

Yes, I think on most Linux machines readlink -f is available. But for BSD based systems, which include Mac OS X, readlink annoyingly does not have -f. I actually have core-utils installed via macports on my machine (and could install it with spack :) but I'd like this to work on a vanilla Mac OS X box.

The current solution in 9bb1f1c is this:

_sp_source_dir=$(cd -P $(dirname "${BASH_SOURCE[0]}") && pwd)
_sp_source_file="$_sp_source_dir/$(basename ${BASH_SOURCE[0]})"  # Bash's location of last sourced file.

It is more awkward than readlink -f but it works. I like the python idea but I am attempting to avoid paying the python startup cost from within shell support scripts. On our machines where Python is mounted over NFS it's actually pretty slow.

If you like this version I'll merge it in...

[malcook]

Hmmm - I understand your considerations about core-utils and python, but, I still don't your solution address the primary issue, being that "share/spack/setup-env.sh fails when executed indirectly from a symlink".

However, upon closer reading I see that you advise:

Source it like this:
#
#    . /path/to/spack/share/spack/setup-env.sh

Oops. I had been sourcing by sym-linking it into /etc/init.d. When I do this, the issue I report arises.

If I follow your advice and instead create an init file which sources it by absolute path, then we no longer have the need for code to resolve the absolute path in the first place.

So, no patch is needed, either mine, or your modified version.

However... I still maintain that your version does not resolve the issue as I observed it. Consider:

When /some/place/share/spack/setup-env.sh is symlinked into /etc/profile.d, say to /etc/profile.d/spack-setup-env.sh, during etc/profile.d processing,

The value of ${BASH_SOURCE[0]} will be /etc/profile.d/spack-setup-env.sh.

And, the value of $(readlink -f "${BASH_SOURCE[0]}") will be "/some/place/share/spack/setup-env.sh" - which is what we need to finding the "_sp_share_dir"

However, the value of $(cd -P $(dirname "${BASH_SOURCE[0]}") && pwd) will be "/etc/profile.d" - from which we can not figure out "_sp_share_dir".

Do you see my point?

In any case, I have a workaround, which is to follow the advice in your documentation.

If there is anything to do, it is to warn spack adopters not to symlink as I did.

Oh, and, learn how to abandon my pull request ;)

Happy spackin'

[adamjstewart]

If we really want support for symlinks, we would need to implement something like what is discussed in this StackOverflow post. Do we still want this? I'm just trying to close out old issues 😄

[malcook]

Thanks for checking. Not on my behalf. Alas we are not using spack.

[alalazo]

@tgamblin Is it OK to close this issue as wontfix?

[becker33]

Closing as no longer requested. If anyone else wants this feature, we can reopen, but so far it looks like no one needs this.

[bebosudo]

We had this kind of problem today when moving out our sourcing from /root/.bashrc.
Linking or copying share/spack/setup-env.sh to /etc/profile.d/ caused the following at login time:

-bash: spack: command not found
-bash: /etc/profile.d/spack-completion.bash: No such file or directory

We solved by adding a file in /etc/profile.d/ that sources directly the full path:

# cat /etc/profile.d/spack-loader.sh
source /opt/cluster/spack/share/spack/setup-env.sh