Bug: configuration of bash failed on macOS, created new .bash_profile, ignored .profile

[darkn3rd]

Bug report

After installing JDK and SDK with sdk cli, my shell environment was misconfigured.

To reproduce

1. Use a .profile to call appropriate shell configuration:

   if [ -n "$BASH_VERSION" ]; then
    if [ -f "$HOME/.bashrc" ]; then
      source "$HOME/.bashrc"
    fi
   fi
   
   if [ -n "$ZSH_VERSION" ]; then
    if [ -f "$HOME/.zprofile" ]; then
      source "$HOME/.zprofile"
    fi
   fi

2. Installation:

   curl -s "https://get.sdkman.io" | bash
   source "$HOME/.sdkman/bin/sdkman-init.sh"
   sdk install java 21.0.3-zulu

Actual Results

A new file was created .bash_profile with

export SDKMAN_DIR="$HOME/.sdkman"
[[ -s "$HOME/.sdkman/bin/sdkman-init.sh" ]] && source "$HOME/.sdkman/bin/sdkman-init.sh"

Because of this, my .profile is never loaded.

I have other tools that are no longer available, because Homebrew env/paths, rbenv, pyenv, asdf (kubectl, terraform), nvm, etc. were not available after installing sdkman.

Expected Results

I expected that sdk could not edit my shell startup files, but would instead prompt to edit them. If I wanted sdk to automatically edit my shell startup files, then I would run something like sdk init.

System info

• macOS 12.6.3 (arm64)
• bash 3.2.57, zsh 5.8.1

• sdk version

  
  SDKMAN!
  script: 5.18.2
  native: 0.4.6

[helpermethod]

@marc0der I suppose if a bash_profile doesn't exist we shouldn't append to it.

[marc0der]

I expected that sdk could not edit my shell startup files, but would instead prompt to edit them.

Most people would opt out and then wonder why SDKMAN isn't working. I'd expect a deluge of support requests. It would also break all noninteracive CI installations that depend on our installation script.

@helpermethod I agree, not creating the file sounds like a better approach. We could also be more explicit in the installation script about what changes we are making to your shell initialisation scripts.

In general, if a file doesn't exist, don't touch it. If we change one, log clearly what we have done.

[darkn3rd]

The question is, do you want to support and test the vast number of variable configurations between Mac/Linux/Win terminal behavior across different shells, and possibly test with other toolchains that modify the shell to make sure no conflicts. Or perhaps, assume that using command line tools should require a minimum familiarity of shell knowledge (segue: this used to be a required course, e.g. "intro to shell (programming)", back in the day). Popular environments like rbenv and pyenv let the user decide and have an option for auto-configure should the users want this.

Some other options are to prompt users if they want autoconfiguration. If you decide to keep the autoconfiguration, could you provide an option turn it off, such as an env var or something? In my use case, installing SDKMAN disrupted 5 other tool chains, so I would rather be prompted on what I need to add to my shell environment, especially as I float between zsh and bash.

[marc0der]

So I went and looked at the code and realised that we had implemented some functionality around this many years ago. For more details, you can read the section Install without modifying shell config on the installation page of our website.