sdk: Global tools are not found on zsh

I´ve ran into the same problem today. Got resolved editing ~/.zshrc, and putting a new line with:

export PATH=$HOME/.dotnet/tools:$PATH

I´ve ran into the same problem today. Got resolved editing ~/.zshrc, and putting a new line with:

export PATH=$HOME/.dotnet/tools:$PATH

This is the answer! Thank so much.

This is going to become a greater usability concern with the next version of macos, where bash is being replaced by zsh.

On Catalina, the default shell is zsh… maybe now time to find a way to fix the installation issue? not just writing how to do it manually 😃

That’s correct, the installer only modifies PATH for bash. The instructions printed when dotnet tool install doesn’t find the tools directory on PATH are also for bash.

For zsh, you’ll need to modify your .zshrc manually to append ~/.dotnet/tools to PATH.

Have you considered simply creating the /etc/paths.d/dotnet-cli-tools file with /Users/username/.dotnet/tools (with the current user name) instead of ~/.dotnet/tools?

Pros:

• Works on all shells (bash, zsh, etc.)
• No need to print instructions on how to make cli tools available for your shell, works out of the box

Cons:

• Only works for the user who installed the .NET Core SDK

In my opinion, the pros largely outweight the cons. Not having .NET cli tools work out of the box is a shame.

Even @RickStrahl got bit by this today:

I can’t get dotnet tools to launch on my Mac. They’re installed & show in dotnet tool list. ~/.dotnet/tools is properly in $PATH, but running any of the Tool commands gets: Command not found.

Going into the tools folder and typing command doesn’t work. From Finder it works???

@wli3 the problem is that the message is not visible enough. It says that the installation was successful, so none really care about reading through the info printed. It should be more visible, maybe in yellow as warning.

It seems it not working on fish shell too. Workaround: it works after this command:

set --universal fish_user_paths $fish_user_paths ~/.dotnet/tools/

Set PATH is tricky on macOS due to path_helper is simple and there is no paths.d. Since in unix, the user are responsible for the PATH configuration. There should be less magic. Maybe a better way is to detect current shell is zsh and print a tailored message that the user can copy paste like the current fallback bash output

We are a few macOS’s in with zsh as a default shell.

Installer still writes export PATH=$PATH:~/.dotnet/tools while it should be writing export PATH=$HOME/.dotnet/tools:$PATH as zsh does “translate” $HOME, and does not translate tilde.

@peterhuene we discussed this in early design. Directly edit Unix user’s profile is not “idiomatic”, even dangerous. And asking user to copy paste adding to path is a good middle ground.

Also that is why we need extra config for auto complete

Yet another casualty: https://github.com/waf/CSharpRepl/issues/36

I see. I created this bug to track it https://github.com/dotnet/sdk/issues/3992

Here is my plan:

We won’t have the same experience as bash shell.

We will print the following instruction.

Tools directory '/USERNAME/home/.dotnet/tools' is not currently on the PATH environment variable.
If you are using zsh, you can add it to your profile by running the following command:
 
cat << \EOF >> $HOME/.zprofile
# Add .NET Core SDK tools
export PATH="$PATH: /USERNAME/home/.dotnet/tools "
EOF

Detail reason: Mac don’t have a good solution to put user path for all user (/USERNAME/home/.dotnet/tools is different for different user). We currently adding literal ~/.dotnet/tools for all users. And that works for bash. But it no longer works for zsh.

At the same time, directly adding new lines to .zprofile is not “idiomatic” for unix. So we can only use existing fallback experience. (bash will have the same experience is you install it via tar.gz).

I find there are 3 ways you can detect the application is running on zsh. (a)$SHELL (b)$ZSH_NAME and use ©ps -p $$

Only (a) can work in a dotnet program. If you run Console.WriteLine(Environment.GetEnvironmentVariable("ZSH_NAME", EnvironmentVariableTarget.Process)); you will get nothing, even when echo $ZSH_NAME can give you the value in the same session. I don’t know why at this moment. © won’t work since $$ is “the current process”. It can only work for scripts. However, the downside of $SHELL is, it will only give you the default shell. That means if you run zsh on top of bash, we will not detect that. I verified in macOS 10.15 VM if it has $SHELL set. (after running chsh -s /bin/zsh)

I’d be glad to file a separate issue for this as well, but it seems relevant to the discussion: My global tools (within a bash shell on macOS) are not discovered by either which or /usr/bin/env, and it would seem to be because these tools are also not expanding the ~ added to PATH from /etc/paths.d/dotnet-cli-tools.

I believe this is causing https://github.com/filipw/dotnet-script/issues/409. Manually adding ~/.dotnet/tools to PATH in my ~/.bash_profile fixes this issue, but it’s not an obvious workaround given that calling tools directly like dotnet-script works without it.

@wli3 thanks for the information. I think it is easy to find articles to support your opinion on internet on any topics, I can easily find some counter links but I will not do that:)

Let’s go back to the actual issue: the current bug is, dotnet only append its path ~/.dotnet/tools in .bash_profile. This is a wrong assumption because a lot of ppl are using non-bash.

And your proposal is to print some warning in the end of sdk installation, to let user manually tune their PATH settings. I think this is a bad idea, because I never need to do that for other programming languages, it is just not user friendly.

So, are you going to add handling for zsh (.zshrc / .zshenv)? I also think that’s not perfect because there are other shell envs. That’s why my proposal is to add tools to /usr/bin or /usr/local/bin for osx/linux because that will support every shell env.

It is up to you MS guys to decide what to do. But I am pretty sure if you keep the current implementation, then every zsh user who install dotnet core and wants to try dotnet tool, will end up having issue, then they will google, then they will find this github issue. They will be disappointed, but they can workaround by adding ~/.dotnet/tools to their PATH. Is that what you want? I am not sure 😃

Oh also, when I mean add ~/.dotnet/tools, I mean with an expanded tilde (when sourced from .zshrc it would expand). zsh does not support ~ on PATH like bash does, i.e. it does not expand ~ when searching it.