-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Unix style which command should be built in as an alias. #2885
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
Comments
credit to @wpostma from PowerShell/PowerShell#2885
I totally understand the appeal (and I'm currently copying that into my own personal profile). Unfortunately, this is dangerous for reasons outlined in #1901 and #929. tl;dr: especially in non-Windows scenarios, shells shouldn't plaster over native binaries on the box because users expect the binaries that they're used to (e.g. In this particular instance, unless we implement all the switches available to GNU That being side, I believe we should eventually do some kind of module that gives PowerShell power users aliases like this. |
Ah. Yes, I can see the need to not hide "which" if it's already in the path. For such a purpose, I think then a new Powershell syntax needs to be defined that allows for polyfills (that is, do not replace which if it's in the path). Current Powershell semantics make it impossible for me to write this and have my profile automatically create a function if there is NO command found matching the name
|
The "see" command is more feature rich (and shorter to type too): |
How is that command different than the built in |
There is an alias up top: New-Alias see Get-CommandDefinition
<#PS#> New-Alias foo bar
<#PS#> New-Alias bar ls
<#PS#> which foo
bar
<#PS#> which Get-ChildItem
Get-ChildItem [[-Path] <string[]>] [[-Filter] <string>] [-Include <
8000
string[]>] [-Exclude <string[]>] [-Recurse] [-Depth <uint32>] [-Force] [-Name] [-UseTransaction] [-Attributes <FlagsExpression[FileAttributes]>] [-Directory] [-File] [-Hidden] [-ReadOnly] [-System] [<CommonParameters>]
Get-ChildItem [[-Filter] <string>] -LiteralPath <string[]> [-Include <string[]>] [-Exclude <string[]>] [-Recurse] [-Depth <uint32>] [-Force] [-Name] [-UseTransaction] [-Attributes <FlagsExpression[FileAttributes]>] [-Directory] [-File] [-Hidden] [-ReadOnly] [-System] [<CommonParameters>]
<#PS#> see foo
#A: foo -> bar
#A: bar -> ls
#A: ls -> Get-ChildItem
# Microsoft.PowerShell.Commands.Management.dll
# Microsoft.PowerShell.Commands.GetChildItemCommand
Get-ChildItem [[-Path] <string[]>] [[-Filter] <string>] [-Include <string[]>] [-Exclude <string[]>] [-Recurse] [-Depth <uint32>] [-Force] [-Name] [-UseTransaction] [<CommonParameters>]
Get-ChildItem [[-Filter] <string>] -LiteralPath <string[]> [-Include <string[]>] [-Exclude <string[]>] [-Recurse] [-Depth <uint32>] [-Force] [-Name] [-UseTransaction] [<CommonParameters>]
<#PS#> which PSConsoleHostReadline
Microsoft.PowerShell.Core\Set-StrictMode -Off
[Microsoft.PowerShell.PSConsoleReadLine]::ReadLine($host.Runspace, $ExecutionContext)
<#PS#> see PSConsoleHostReadline
#F: PSReadline\PSConsoleHostReadline
Microsoft.PowerShell.Core\Set-StrictMode -Off
[Microsoft.PowerShell.PSConsoleReadLine]::ReadLine($host.Runspace, $ExecutionContext) |
It is dup #1975 |
credit to @wpostma from PowerShell/PowerShell#2885
credit to @wpostma from PowerShell/PowerShell#2885
My most frequent annoyance on Powershell is typing in a Unix command that everybody knows and unlike ls, or echo or cd, it doesn't just work. The one I find myself missing most often is
which
, which I define on my own system as:That makes me happy on my computer and sad on everyone else's computer where I can't just go install my powershell profile, so I have to go copy and paste that from somewhere into my session, just so I can save myself typing the horrific long forms in over and over. It seems to me that
which
is so darn useful that the above alias should just exist by default in powershell.Searching for a binary in the path is a frequent task, and the above long-form command that my alias saves you from typing is among the most egregious examples of a COBOL-like verbosity in PowerShell that I find completely distasteful. I can't remember all that crap.
which foo
and you're done.Now that powershell is cross platform, and a very useful tool on any system where it can run, including Unix systems, it seems that
which
should make the trip.which
defined as above, works for aliases, and, functions, and binary tools on the path. That makes it an essential tool in your toolbox, and should be covered by the "obviously, should just work" criteria.The text was updated successfully, but these errors were encountered: