Sdk: Better PATH handling on macOS of different shell

[wli3]

In order for tools to be available from command line, CLI need to add ~/.dotnet/tools to PATH on macOS. This need to be a user specific path. But path_helper is machine level. CLI ends up adding literally ~/.dotnet/tools with tilde to the PATH during installer. But the problem is, not all shell support finding tools with PATH like that, like zsh

[dasMulli]

@wli3 the zsh issue is something different, the oh-my-zsh installer reads $PATH at install time and writes export PATH="all:that:I:know:now" to the user's ~/.zshrc file.
To handle this, a tool would need to add to that file or find the line.

oh-my-zsh has caused issues before (https://github.com/dotnet/cli/issues?q=is%3Aissue+oh-my-zsh+is%3Aclosed) and at some point there was a known issues document. oh-my-zsh breaks everything that needs to add to the path, there isn't really a good way to solve this. some will have changed their line to export PATH="things:at:install:$PATH" and not experience any problems.

Putting a resolved path into /etc/paths.d should be avoided at all costs. It either breaks some users on shared systems (only one file name used) or cause weird behavior when multiple valid user paths are on the PATH and you can't figure out why your tool version update doesn't work (e.g. multiple users are admins, a paths.d file for every user).

I believe all major shells handle tilde expansion in $PATH, not sure though. (maybe @omajid knows?)

If it isn't possible to use /etc/paths.d, then a message or help should be provided for users to edit their .bash_profile, .zshrc, .fishrc etc. if the expected path isn't found in the current PATH which can get quite messy.

[spboyer]

+1 also have to add exec permissions on the /tools folder

[wli3]

dotnet tool install did detect PATH and print instruction when the tool path are not in it.

Given the "non mac standard" config of zsh, it would be too complex and error prone for SDK to jam the tool path in (by the option in this thread and the latest year thread). Let's see if there is any zsh user cannot resolve this issue by the instruction. If so. we might need to consider detect current shell and print specific message for zsh. Close it for now