dotnet: command not found Mac OS X 10.11.4, dotnet-osx-x64.1.0.0-rc2-3002702.pkg

[shawnrc]

Steps to reproduce

1. Run the latest released .NET Core pkg installer: dotnet-osx-x64.1.0.0-rc2-3002702.pkg.
2. Pull up a fresh instance of your preferred shell.
3. Run dotnet

Expected behavior

dotnet executes and probably prints usage information because no specific command was passed.

Actual behavior

I'm given this output:

zsh: command not found: dotnet

Environment data

dotnet --info output:

shawn ~  dotnet --info
zsh: command not found: dotnet

¯_(ツ)_/¯

normandy:~ shawn$ /usr/local/share/dotnet/dotnet --info
.NET Command Line Tools (1.0.0-preview1-002702)

Product Information:
 Version:     1.0.0-preview1-002702
 Commit Sha:  6cde21225e

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.11
 OS Platform: Darwin
 RID:         osx.10.11-x64

This package was found at https://go.microsoft.com/fwlink/?LinkID=798388, and was not the link specified at the actual instruction guide at https://www.microsoft.com/net/core#macosx.

Verifying the hash:

shawn ~ shasum ~/Downloads/dotnet-osx-x64.1.0.0-rc2-3002702.pkg -a 512
5f00fd91e1bbffe55d091c398913847bab0766ab00987d9164826a1c15f2b05eb8b56f801c0625b75161237dd31eb9180b6468b2bbd9c85077caf2fb4cae6e7a  /Users/shawn/Downloads/dotnet-osx-x64.1.0.0-rc2-3002702.pkg

It's also worth mentioning that dotnet does, in fact, exist at /usr/local/share/dotnet/dotnet, but there's definitely no symlink in /usr/local/bin/. While there's definitely no symlink, the more I read about this issue, the more it seems like that's intentional. This is most likely actually a duplicate of #5193 and highlights the insufficiency of using path_helper for zsh users.

[wenjiangtao]

same problem with u, still do not how to fix it.

[dasMulli]

If you created symlinks manually, they may point to a different directory. execute ls -l $(which dotnet) to see if you have a broken symlink (e.g. pointing to a dotnet/bin directory).
If there is no symlink, you may need to create one manually.

[dasMulli]

Also note that there is another zsh related issue thread: #5193

[flyingsky]

I just open a new terminal, it works. It's the first time to install. If I use existing terminal before the installer, it seems the path is not effect, so cannot find command 'dotnet'.

[shawnrc]

@wenjiangtao The quick fix is to just run ln -s /usr/local/share/dotnet/dotnet /usr/local/bin/, which will get you a working dotnet, but doesn't change the fact that adding the entry for dotnet in /etc/paths.d/ doesn't seem to work well for zsh users.

@dasMulli I haven't made any symlinks to the dotnet binary before, and there was nothing referencing it in /usr/local/bin/ at that point.

Also, in reference to that issue, I think the more sensible option would be to just create a symlink in /usr/local/bin/ - it's very likely to already be part of a user's PATH since the project requires you to have brew set up and the latest openssl installed. It seems like zsh doesn't use path_helper by default, or at least, not in the way that the dotnet maintainers expect it to.

@flyingsky I'm not sure if the installer actually added a symlink to /usr/local/bin/ or if zsh actually runs path_helper on your system, but I was definitely not able to run dotnet after opening a new shell or a new instance of zsh. Or maybe I shouldn't assume you're a zsh user, haha.

[blackdwarf]

What would help, guys, was if any of you would post your .zshrc files and specify are you using oh-my-zsh.

[blackdwarf]

Or, at least post how is your path in said files configured. This seems to be the common thread/culprit for this problem.

[pofallon]

I ran into the same issue. I'm using oh-my-zsh. Here's the relevant portion of my ~/.zshrc:

# User configuration

export PATH="/Library/Java/JavaVirtualMachines/jdk1.8.0_51.jdk/Contents/Home/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin"

Manually creating the symlink to /usr/local/bin/ fixed it for me.

Thanks!

[blackdwarf]

@pofallon one question: how did you install go? Using brew or their PKG?

[pofallon]

Good question -- I don't remember :) Most of that predated my switch to zsh (I haven't been using zsh very long).

[pofallon]

Same process on a different Mac -- same results, and same fix worked. Also using oh-my-zsh. Here's the relevant PATH info:

# User configuration

export PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/paul/.rvm/bin:/usr/local/share/dotnet/bin"

I had to manually fix the .rvm stuff when moving to .zsh. I don't remember if I manually added the /dotnet/bin path entry (from RC1) or if an installer added that for me.

[blackdwarf]

@pofallon aha, good. :) Good in the sense that then I know what the problem is.

So it seems that the main culprit here is the way installer for oh-my-zsh works. It creates a .zshrc file and then puts the $PATH exploded in there. That means that it will overwrite whatever dynamic path is being created using path_helper when you launch a new session of zsh.

The only way to solve this, apart from filing a bug on zsh project, is to back away from using /etc/paths.d/ and go back to symlinking the muxer in /usr/local/bin or /usr/bin even.

/cc @brthor @piotrpMSFT

[shawnrc]

@blackdwarf Good catch! I also found a similar offending line in my .zshrc:

export PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin"

At this point, it's been so long since I set up zsh on my machine that I honestly can't remember what's responsible for that line in there, but oh-my-zsh is definitely a likely culprit. To resolve the issue on my end, I've changed the export to this:

export PATH="/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:$PATH"

Which then allows me to do this:

shawn ~ which dotnet
/usr/local/share/dotnet/dotnet

Cheers!

[blackdwarf]

After some thinking about this, I think that this is really a problem of various different shell installers. We will have documentation to essentially have a workaround to add the symbolic link manually.

[jamisonwight]

I had the same problem and found that closing my terminal sessions and reopening a new terminal fixed this issue as @flyingsky stated.

[aliozgur]

Adding /usr/local/share/dotnet to the PATH in .zshrc fixed the problem in my case

# Add .NET to $PATH
export PATH="/usr/local/share/dotnet:$PATH"