Modify 'bash_profile' rather than 'bashrc' by default?

[eayus]

Currently I believe the GHCup installer will prompt the user if they would like to prepend/append the GHCup bin path to their .bashrc file. However, I wonder if it makes more sense to modify .bash_profile instead, as this will allow the path to be seen by non-command line programs. I've ran into issues where editors using the LSP will not work unless launched from the command line, as they cannot find the ghcup executable. I think this can be confusing for newcomers to Haskell.

[ulidtko]

Yes, and... you could go further. Much further.

Why not target ~/.profile instead? That achieves what you say @eayus (affect both interactive & non-interactive sessions) -- and is also non-bash-specific. There's no good reason for an addition to PATH to be bash-only -- see your /etc/shells -- and besides the more arcane shells like tcsh, ksh, I known people do still use zsh; and the user can also have tmux as their "login shell" (which is the first one that runs in ssh session, or in desktop terminal emulator tabs, VSCode terminals or whathaveyou).

I myself use the fish shell -- which is a whole different story. It has "universal variables" which autopersist; and I don't need to edit any files whatsoever to add a location to PATH.

For the fish-less systems, I'm also not happy with all the bulky generated snippets that every goddamn installer shoves into that poor bashrc; without manual intervention, it quickly becomes a hot mess. FWIW, there's this in my .profile:

maybe_append_paths "$HOME/.local/bin"
maybe_append_paths "$HOME/.cabal/bin"
maybe_append_paths "$HOME/.ghcup/bin"
maybe_append_paths "$HOME/.cargo/bin"
maybe_append_paths "$HOME/.bun/bin"

and some other things; with maybe_append_paths defined thusly:

#-- An abbreviation to shove stuff into $PATH.
#--
#-- Uses this posix trick for idempotence https://stackoverflow.com/a/8811800/531179
#-- to not clutter PATH with copies of a directory when source'd multiple times.
#--
#-- $d is only appended when: 1) it's not already in PATH, 2) it's an existing dir.
maybe_append_paths() {
    for d in "$@"; do
        test ":${PATH#*"$d"}:" = ":$PATH:" && test -d "$d" && PATH="$PATH:$d"
    done
}

Then there's /etc/paths on OSX.
Then there's Windows (and WSL, and Cygwin, and MSYS).
Then there're people's dotfiles.
Then there're DevContainers interfering with filesystem paths, and what other docker nonsense.

... The rabbit hole gets super deep, as long as you care. Thus, for installer maintainer, it becomes a fairly tough call -- to try to fully-correctly fully-generically address people's PATH needs.

For this reason, if I were a GHCup maintainer (which to be clear, I'm not) -- I'd acknowledge this as indeed a request for improvement, but give it a hard KISS and decline. If you think that's the problem you got -- quite frankly, open your editor, grab that snippet from .bashrc and move it to .bash_profile yourself, takes two seconds; can't you?

[eayus]

I agree that modifying .profile is better than .bash_profile, so that other SH compatible shells will be supported too.

Honestly I don't see how modifying .bashrc is any simpler than modifying .profile. The installer will never match everyone's exact requirements, but it makes sense to choose a sensible default which will work well for the majority of people. Given how common it is to use a non-CLI editor like VSCode, in my opinion it makes sense to facilitate that.

Of course I can modify .bash_profile myself (which I have done). My point is not that this is some irremediable problem, but that it would be more convenient if I didn't have to do that. For a newcomer who opens VSCode for the first time after installing Haskell to be met with some confusing error about how it can't find GHCup, they may not figure out that they need to modify .profile as the solution.