-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Comments
fix github #32: share/spack/setup-env.sh fails when executed indirectly from a symlink
fix github #32: share/spack/setup-env.sh fails when executed indirectly from a symlink
@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 Consider:
but
whereas
Perhaps considering this is a python project is to use python's os.path.realpath
|
@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 The current solution in 9bb1f1c is this:
It is more awkward than If you like this version I'll merge it in... |
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:
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 However, the value of 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' |
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 😄 |
Thanks for checking. Not on my behalf. Alas we are not using spack. |
@tgamblin Is it OK to close this issue as |
Closing as no longer requested. If anyone else wants this feature, we can reopen, but so far it looks like no one needs this. |
We had this kind of problem today when moving out our sourcing from -bash: spack: command not found
-bash: /etc/profile.d/spack-completion.bash: No such file or directory We solved by adding a file in # cat /etc/profile.d/spack-loader.sh
source /opt/cluster/spack/share/spack/setup-env.sh |
Removed python, and added cmake, and pkg-config to list of external packages.
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:Agreed?
I tested in zsh too.
I promise I will get with the pull-requests soon.
~Malcolm
The text was updated successfully, but these errors were encountered: