Tool with command name dotnet-foo is not available as cli verb

[dasMulli]

Steps to reproduce

1. Create and install a tool with

  <PropertyGroup>
    <ToolCommandName>dotnet-greet</ToolCommandName>
  </PropertyGroup>

2. execute dotnet-greet, observe that the program runs
3. execute dotnet greet, observe that the program does not run

No executable found matching command "dotnet-greet"

Workaround:

Martins-MacBook-Pro:~ martin$ cp ~/.dotnet/tools/dotnet-greet /usr/local/bin/
Martins-MacBook-Pro:~ martin$ which dotnet-greet
/usr/local/bin/dotnet-greet
Martins-MacBook-Pro:~ martin$ dotnet greet
Hi martin!

Expected behavior

Tools named dotnet-{x} should be available as CLI verb to be used as dotnet {x}.

Actual behavior

The CLI does not search PATH entries prefixed with ~/ for candidate executables and fails to run the global tool as CLI verb.

Environment data

dotnet --info output:

.NET Command Line Tools (2.1.300-preview2-008012)

Product Information:
 Version:            2.1.300-preview2-008012
 Commit SHA-1 hash:  c9ac5c9c02

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.13
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/2.1.300-preview2-008012/

Microsoft .NET Core Shared Framework Host

  Version  : 2.1.0-preview1-26116-04
  Build    : eeb3a84e2142aba791fe003564b8afd048c45ff9

cc @wli3 @livarcocc

[livarcocc]

@dasMulli thanks for the bug report.

I assume this is a global tool? And also that your failing command there is for dotnet greet instead of dotnet-greet?

[dasMulli]

Yes the repro was supposed to be a CLI verb to be packed and installed as global tool.

[dasMulli]

Repo at:
https://github.com/dasMulli/GlobalCliToolsExample

[dasMulli]

Works just fine on windows, just not when using all the defaults on Mac. (didn't try any linux)

[wli3]

as @dasMulli stated, resolver should find dotnet-X on the PATH and make it dotnet X. And due to mac path_helper limitation, what ends up on the PATH start with "~/" (Linux should be fine). Let me see if we can do something on the command resolver.

[wli3]

This will be a problem for dotnet-watch, the walk around is adding path by bash_profile, which is the instruction if the user install via a tar.gz. Copy paste the following to shell

cat << EOF >> ~/.bash_profile
# Add .NET Core SDK tools
export PATH="$PATH:$HOME/.dotnet/tools"
EOF

cc @natemcmaster

[wli3]

Here is the problem
https://github.com/dotnet/cli/blob/fffe3142ad8043743d83885df2166fd2f80dceca/src/Microsoft.DotNet.Cli.Utils/EnvironmentProvider.cs#L72-L80

it simply do a join and search. It won't expend the path with ~/ or $HOME

[dasMulli]

exactly. a bit earlier the search paths are calculated

https://github.com/dotnet/cli/blob/fffe3142ad8043743d83885df2166fd2f80dceca/src/Microsoft.DotNet.Cli.Utils/EnvironmentProvider.cs#L43-L50

it may make sense to walk over the list again in *nix to do a ~/ replacement.