-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Global tools are not found on zsh #9415
Comments
I don't believe this will work without a profile, because in that case, we won't be able to load the PATH env variable with a path to the shim folder. cc @peterhuene @wli3 |
That's fair, I just added that in to sidestep instructions to remove any path modifications from my own profile. I have very little in there, though, just some hand-rolled command completions. |
That's correct, the installer only modifies For zsh, you'll need to modify your |
Oh also, when I mean add |
So would it be better to use $HOME then? Or is the problem no sort of expansion at all? |
Should be the same depending on how you set |
I didn't set it at all, the |
Ah, gotcha, that is from the installer. Unfortunately macOS is reading I don't know if Having the extraneous entry from |
alternatively, is this something where at install-time we know where the tools root is and could write the full path? |
By default, Personally, I think we should remove this behavior from the installer and make the first run experience for the user "smarter", where it can detect the shell being used and modify the user's profile accordingly. It would require users to source the profile again or restart their shell after the first time dotnet is run, though. I looked over the source to |
I don't think that's too much to ask, honestly. Thanks for digging! |
the oh-my-zsh installer has made some problems already (TL;DR there is no real way to reliably work around how oh-my-zsh sets up a user's environment to perform the PATH modification): |
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 |
Why not let dotnet tool create symlink under /usr/local/bin, like what npm does? Then you don't need to worry about different shell environments. |
@txchen do symlink will require sudo for install and uninstall. It blocks user who don't have sudo access. And there is also security implication as the result of that. I am curious about "install tool for every user on the same machine" case. What is your scenario? |
@wli3 At least on my MacOS, npm install which does the symlink does NOT require sudo. I have write permission on As for the What dotnet tool offers now is actually user level tool, not "global". IMO, you probably should take a look at npm's implementation because that's mature proven solution. If you only modify .bash_profile, of course zsh users like me will not be happy, so why not using symlink on linux/osx? |
@wli3 you are right that creating symlink under /usr/local/bin or /usr/bin, will sometimes require sudo permission. I think that's okay because To solve this maybe you can create a "user-level switch", but by default, dotnet tool install -g should do system global level installation, IMO. |
@txchen https://givan.se/do-not-sudo-npm/ |
@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 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 |
I'll chime in to add that it isn't completely unheard of for users to have to explicitly add something to For example, That said, I think we can do better here. I'd like to remove the installer logic of adding something to Instead, I think the first-run experience for One caveat is that the first-run sentinel file would then need to be shell-specific, since if I'm using bash and run |
@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 |
@txchen the actual issue is in the oh-my-zsh installer that users use to install OMZ: ohmyzsh/ohmyzsh#4317, ohmyzsh/ohmyzsh#1359, ohmyzsh/ohmyzsh#3960 by [@]robbyrussell
If someone installed zsh using oh-my-zsh AFTER the dotnet CLI set up the global tools, then everything would be fine. |
@dasMulli I am pretty sure that on all my machines, I install zsh first, then install OMZ. (I think without zsh, you cannot install omz). So it is not Please double confirm, and don't blame OMZ too fast. |
@txchen yes of course, I blame Friday ^^ There's really two issues here:
|
It seems it not working on fish shell too. set --universal fish_user_paths $fish_user_paths ~/.dotnet/tools/ |
I´ve ran into the same problem today. export PATH=$HOME/.dotnet/tools:$PATH |
Thanks, @bilal-fazlani and @gabrielrb! That would be the recommended way to get this to work for fish and zsh, respectively, for now. |
This also has another annoying side effect, even if you are using bash. Process.Start(
new ProcessStartInfo(cmds[0], cmds[1]) {
UseShellExecute = false
}
)?.WaitForExit(); Replacing "~" with fully qualified $HOME path, works just fine. Don't think I need to open another bug for this since it is another manifestation from this same issue. If you still want me to open another issue, let me know. |
I'd be glad to file a separate issue for this as well, but it seems relevant to the discussion: I believe this is causing dotnet-script/dotnet-script#409. Manually adding |
I had the same problem as @bmsantos. My workaround is the following: // Expand the default paths for tools on different platforms.
var home = Environment.ExpandEnvironmentVariables("%HOME%");
if(System.Runtime.InteropServices.RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
home = Environment.ExpandEnvironmentVariables("%USERPROFILE%");
}
var process = new Process()
{
StartInfo = new ProcessStartInfo()
{
WorkingDirectory = $"./{functionId}",
RedirectStandardOutput = true,
RedirectStandardError = true,
UseShellExecute = false,
CreateNoWindow = true,
FileName=$"{home}/.dotnet/tools/hypar", // Use the full expanded path to your tool.
Arguments="init"
}
}; Of course, this only works for dotnet global tools installed in the default location. |
@ikeough would 'which dotnet' help you resolve that location ? |
Possibly. I didn't realize that the global tools were installed in the same location as dotnet. And, I think that would only work on *nix right? |
In this case manually append |
its work for me thank you dear |
This is going to become a greater usability concern with the next version of macos, where bash is being replaced by zsh. |
Here is my plan: We won’t have the same experience as bash shell. We will print the following instruction.
Detail reason: At the same time, directly adding new lines to I find there are 3 ways you can detect the application is running on zsh. (a) Only (a) can work in a dotnet program. If you run |
This is the answer! Thank so much. |
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 :) |
it is done. the latest sdk will print out instruction to ask you to copy paste scripts in order to add the path to your .zshrc path_helper no longer can put it on path for zsh magically. |
@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. |
I see. I created this bug to track it #3992 |
Have you considered simply creating the Pros:
Cons:
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:
|
Yet another casualty: waf/CSharpRepl#36 |
We are a few macOS's in with zsh as a default shell. Installer still writes |
zsh does understand and expand the tilde (~). The dotnet installer is not 'writing' an export statement. It is adding a file in /etc/paths.d named dotnet-cli-tools that contains |
Thank you @jrdodds for clarification. I recently installed dotnet on Raspberry Pi 4 and the same problem was observed. However, I failed to find anything at |
@maxpavlov My understanding is that the path_helper tool and the |
The below example is for FAKE but I can repro with other global tools as well, such as
weeknumber
. I tried to remove any profile customizations from my profile by running zsh without them and the problem persists. I've provided my PATH as well to show that the global tools dir is in fact in there.Steps to reproduce
zsh --no-rcs
dotnet tool install -g fake-cli --version '5.0.0-*'
fake
Expected behavior
The FAKE cli help should display
Actual behavior
The shell reports that
fake
could not be found.Known workarounds
~/.dotnet/tools/fake
Environment data
dotnet --info
output:$PATH:
The text was updated successfully, but these errors were encountered: