Run a command that's not installed on your Linux machine, e.g. dtrace
.
jasonsh@jasonsh-ubd02:~$ dtrace
The program 'dtrace' is currently not installed. You can install it by typing:
sudo apt-get install systemtap-sdt-dev
PS> dtrace
dtrace : The term 'dtrace' is not recognized as the name of a cmdlet, function, script file, or operable program. Check
the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ dtrace
+ ~~~~~~
PS /home/jasonsh> $PSVersionTable
Name Value
---- -----
PSVersion 6.0.0-alpha
PSEdition Core
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 3.0.0.0
GitCommitId v6.0.0-alpha.9
CLRVersion
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
PS /home/jasonsh> uname -v
#49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC 2016
That would be nice! Is there some repo/registry that maintains the mapping of "command to pkg name" for the various Linux distro's, as well as the pkg mgr to use (apt-get vs yum vs Install-Module)?
This isn't built-in bash
functionality; it's normally defined as an error-handler callback (for error 127) in one of the system-wide shell profiles (probably in /etc/bashrc
, /etc/profile
, or /etc/profile.d/*
).
@rkeithhill It's not likely. Distros that support this kind of functionality generally do two or three things:
I don't think that using or maintaining an unofficial, centralized database of command-to-package mappings or package contents for multiple versions of multiple distros is the right approach. Instead, I think that Powershell should provide relevant error-handler hook points (or use existing ones) in the command loop and let Powershell packagers write callbacks tailored to their specific OS/package manager combination. This is in line with the existing practice above, and should require minimal effort to maintain.
Need some api in PSGallery to enable this
I think that Powershell should provide relevant error-handler hook points (or use existing ones) in the command loop
FYI: there's been a "command not found" action available in PowerShell since version 3.
$executioncontext.InvokeCommand.CommandNotFoundAction = {
param ($e, $e2)
$e2.StopSearch = $true
$e2.CommandScriptblock = {
Write-Verbose -Verbose `
"Look for a module containing the command '$e somewhere"}.GetNewClosure()
}
}
It turns out that the gallery does give you a way to look up modules containing a command Find-Module -Command
. So adding that to the hook code, you get something like this:
$ExecutionContext.InvokeCommand.CommandNotFoundAction = {
param ($n, $e)
$e.StopSearch = $true
$e.CommandScriptBlock = {
Write-Host -ForegroundColor Yellow `
-Verbose "Command '$n' was not found; searching on-line for modules with this command"
$result = Find-Module -Command $n
if ($result)
{
$result | Out-String | Write-Host -ForegroundColor Yellow
}
else
{
Write-Host -ForegroundColor Yellow "No matching modules were found."
}
}.GetNewClosure()
}
The response from the gallery can be a bit slow, but you can always cancel the lookup with ctrl-C.
Opened https://github.com/PowerShell/PowerShellGet/issues/287, if they can get the perf down to 100ms or less, I think we can add this capability into PSCore6 (but probably need to have it timeout after 250ms to not impact the interactive experience)
Web response time is not predictable. Can we use local cache like for help files? We could download a catalog and only check the catalog version and suggest users to update it.
What about changing the CommandNotFoundException
to this:
<data name="CommandNotFoundException" xml:space="preserve">
<value>The term '{0}' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
You can also try to find a module containing {0} online:
Find-Module -Command {0}</value>
It's not as fancy as looking up an actual module automatically, but it does point users in the right direction, and it's super easy to implement.
Maybe the extra line I propose here should only be displayed when {0} -match "^\w+-\w+$"
(this probably is not 100% correct regex to capture CmdLet verb-noun, but you get the idea).
I believe this functionality belongs to package management, but of course, it can/should be shipped together with PowerShell. I did proof-of-concept module which finds required information in about 20ms, so adding suggestions is not a problem. It is inspired with apt-get update
from Linux, and it follows what Ilya described above. More information is in the issue Steve opened.
It will nice to have a public API (in PowerShellGet?) for fast search from the local cache - we could use the API in PowerShell engine for Help and IntelliSense subsystems. Perhaps PowerShell engine need generic API to search from some sources (preinstalled modules, custom modules, native commands and so on).
Can also integrate with winget
Most helpful comment
I believe this functionality belongs to package management, but of course, it can/should be shipped together with PowerShell. I did proof-of-concept module which finds required information in about 20ms, so adding suggestions is not a problem. It is inspired with
apt-get update
from Linux, and it follows what Ilya described above. More information is in the issue Steve opened.