From 763be30c08912ccead97e22206f33fe213df0d4d Mon Sep 17 00:00:00 2001 From: Zlatko Knezevic Date: Wed, 25 May 2016 09:21:57 -0700 Subject: [PATCH] Update known-issues.md (#3240) Add updated information to the known issues document about the oh-my-zsh problem and how to solve it. skip ci please Fixes #3063, #1567 --- Documentation/known-issues.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/known-issues.md b/Documentation/known-issues.md index 5560f2e55..fbc54d56d 100644 --- a/Documentation/known-issues.md +++ b/Documentation/known-issues.md @@ -22,20 +22,21 @@ sudo port -f uninstall openssl @0.9.8 You can verify whether you have the right version using the `openssl version` command from the Terminal. ## Users of zsh (z shell) don't get `dotnet` on the path after install -There is a problem with the way `path_helper` interacts with `zsh` which makes `dotnet` not appear on the path even though -the install places the file properly in the `/etc/paths.d/` directory. +There is a known issue in oh-my-zsh installer that interferes with how `path_helper` works on OS X systems. In short, +the said installer creates a `.zshrc` file which contains the exploded path at the time of installation. This clobbers +any dynamically generated path, such as the one generated by `path_helper`. -**Issues tracking this:** +There is an [outstanding PR](https://github.com/robbyrussell/oh-my-zsh/pull/4925) on the oh-my-zsh repo for this. -* [#1567](https://github.com/dotnet/cli/issues/1567) - -**Workaround:** symlink the `dotnet` binary in the installation directory to a place in the global path, e.g. `/usr/local/bin`. +**Workaround 1:** symlink the `dotnet` binary in the installation directory to a place in the global path, e.g. `/usr/local/bin`. The command you can use is: ```console ln -s /usr/local/share/dotnet/dotnet /usr/local/bin ``` +**Workaround 2:** edit your `.zshrc` and/or `.zshprofile` files to add the `/usr/local/share/dotnet` to the $PATH. + ## On dev builds of the tools, restoring default project from dotnet new fails When using non-release versions of the CLI, `dotnet restore` will fail to restore `Microsoft.NETCore.App` because for that particular version it exists on a NuGet feed that is not configured on the machine. This behavior is by design and does not happen with public releases (such as RC2). @@ -104,4 +105,3 @@ get information and get unblocked. # What is a "known issue"? A "known issue" is a major issue that block users in doing their everyday tasks and that affect all or most of the commands in the CLI tools. If you want to report or see minor issues, you can use the [issues list](https://github.com/dotnet/cli/issues). -