Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
malcook opened this issue Apr 16, 2015 · 9 comments
Closed
Assignees
Labels
bug Something isn't working

Comments

@malcook
Copy link

malcook commented Apr 16, 2015

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 tgamblin self-assigned this Apr 27, 2015
malcook pushed a commit to malcook/spack that referenced this issue May 13, 2015
tgamblin pushed a commit that referenced this issue May 13, 2015
fix github #32: share/spack/setup-env.sh fails when executed
indirectly from a symlink
@tgamblin
Copy link
Member

@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.

tgamblin pushed a commit that referenced this issue May 14, 2015
fix github #32: share/spack/setup-env.sh fails when executed
indirectly from a symlink
@malcook
Copy link
Author

malcook commented May 14, 2015

@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
Copy link
Member

@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
Copy link
Author

malcook commented May 15, 2015

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
Copy link
Member

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
Copy link
Author

malcook commented Oct 13, 2016

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

@adamjstewart adamjstewart added bug Something isn't working and removed feature labels Nov 9, 2016
@alalazo
Copy link
Member

alalazo commented Jan 10, 2017

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

@becker33
Copy link
Member

becker33 commented Aug 7, 2017

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

@becker33 becker33 closed this as completed Aug 7, 2017
matz-e pushed a commit to matz-e/spack that referenced this issue Sep 3, 2018
matz-e pushed a commit to matz-e/spack that referenced this issue Oct 1, 2018
@bebosudo
Copy link
Contributor

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

matz-e pushed a commit to matz-e/spack that referenced this issue Jan 28, 2019
tgamblin pushed a commit that referenced this issue Jul 1, 2019
Removed python, and added cmake, and pkg-config to list of external
packages.
haampie referenced this issue in haampie/spack Dec 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants