Version switch affects all open terminals about sdkman-cli HOT 13 CLOSED

Perhaps the most sensible thing to do is store the currently selected candidate versions in an environment variable. It looks like that's what rvm does. That would mean setting (for example) GRAILS_HOME and PATH based on the currently active version.

from sdkman-cli.

Wow, this is hard. rvm does it by installing itself as a shell function. Otherwise, there is no way to affect the environment of the caller (meaning the script can't set GRAILS_HOME for example). Will have to label this one as tough or impossible :)

from sdkman-cli.

Been giving this one some thought since yesterday and shouldn't be too difficult to do.

Conveniently, we can fabricate the home folder names based on the candidate name uppercased + _HOME, ie. grails -> GRAILS_HOME. Next we add our version on top as environment variable (derived from the grails use GRAILS_VERSION command) $GRAILS_HOME/$GRAILS_VERSION, and lastly, we clobber the previous entry of GRAILS_HOME in the PATH by prefixing our new GRAILS_HOME:

export PATH="$GRAILS_HOME/$GRAILS_VERSION/bin:$PATH"

Going to be a nice one to implement 👍

from sdkman-cli.

Unfortunately we can't overwrite PATH unless we source the gvm script. And the gvm script is not designed for this because if you try it, your terminal closes 😮

from sdkman-cli.

Hahaha! It's a challenging one then.

from sdkman-cli.

So, my general idea is to follow the path of rvm and install gvm as a shell command. This will allow it to modify environment variables in the current shell.

The first step is to rename all internal functions with something like a __gvmtool_ prefix (so they don't pop up in normal bash auto-completion). The main function will simply be called gvm. The only thing I'm not sure how to do is handle the exit() calls as those will kill the shell - not ideal!

I assume that the return code from the function is treated as the 'process' exit code, but that would need to be checked.

from sdkman-cli.

BTW, I don't know whether you want to support both the old behaviour and the new. That can probably be done if you can get the gvm script to work without sourcing it. However, you'd probably want to use exit in that mode of operation. Tricky.

from sdkman-cli.

I'm working on this atm

from sdkman-cli.

@pledbrook give me a shout if you want to have a Skype this evening to talk about possible solutions.

from sdkman-cli.

I'll hopefully have something by tomorrow evening. I think I understand how bash variables and functions work and it doesn't look like it will be particularly difficult to achieve what I'm after. Certainly loading gvm as a function in the shell seems pretty straightfoward.

I'll let you know how it goes.

from sdkman-cli.

@marcoVermeulen We need to nail down how extensions/plugins will work. It's very easy to call a plugin script from the gvm() function if it's in a known place, but it's slightly trickier if we're to pull the script off the path.

More problematic than that is how we expect people to write these scripts. If we call the scripts directly, they do not by default have access to the internal __gvmtool_*() functions, since these aren't copied into the sub-shell. The scripts could source gvm directly, but where would they get it from? By default, they don't have access to a GVM_DIR environment variable.

Sourcing the extension script gives it access to the shell functions, but then all the variables it exports and functions it defines are added to the current shell. Do we want that? I think I'd prefer to ensure that GVM_DIR is available to these scripts so that they can source gvm or gvm-init.sh themselves if necessary.

Thoughts?

from sdkman-cli.

All you say is sounding good. I'll have a poke around in your code during the day tomorrow to see how you have gone about it.

from sdkman-cli.

Closing with reference to issue #82

from sdkman-cli.