Closed svirpridon closed 3 years ago
I also encountered this bug. The reason I want to use asdf-direnv is the huge boot performance improvement:
Standard asdf:
$ time node -v
v14.14.0
________________________________________________________
Executed in 487.45 millis fish external
usr time 270.40 millis 82.00 micros 270.32 millis
sys time 394.76 millis 494.00 micros 394.26 millis
Using asdf-direnv:
$ time node -v
v14.14.0
________________________________________________________
Executed in 9.91 millis fish external
usr time 4.75 millis 97.00 micros 4.65 millis
sys time 3.70 millis 507.00 micros 3.20 millis
Thanks for providing this bug report @svirpridon especially with your investigations. I'll need to see if asdf-direnv
provides any env vars or context information for me to detect when it is in use :thinking:
Apologies for the really late reply, I didn't get a notification about this issue :upside_down_face: (need to check my notification settings)
The solution with ${BASH_SOURCE[0]}
should work fine. Even upstream plugins use this approach: https://github.com/asdf-vm/asdf-ruby/blob/master/bin/exec-env
@hollow I am open to receiving PRs. I would like to know if that syntax changes the required bash version and how, do you happen to know if it will have an affect on this?
Describe the bug
asdf-gcloud's exec-env assumes it is being run directly, not sourced by asdf-direnv.
Steps to reproduce
Expected behavior
Additional context
Changing bin/exec-env's line 6 to
source "$(dirname "$BASH_SOURCE")/../lib/utils.bash"
fixes the problem under asdf-direnv, but likely won't work under no-direnv-asdf.