8000 Unix style which command should be built in as an alias. · Issue #2885 · PowerShell/PowerShell · GitHub
[go: up one dir, main page]

Skip to content

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

Closed
wpostma opened this issue Dec 14, 2016 · 6 comments
Closed

Unix style which command should be built in as an alias. #2885

wpostma opened this issue Dec 14, 2016 · 6 comments
Labels
Resolution-Duplicate The issue is a duplicate. WG-DevEx-Portability authoring cross-platform or cross-architecture modules, cmdlets, and scripts

Comments

@wpostma
Copy link
wpostma commented Dec 14, 2016

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:

function which($name)
{
    Get-Command -Name $name | Select-Object -ExpandProperty Definition
}

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.

@joeyaiello joeyaiello added the WG-DevEx-Portability authoring cross-platform or cross-architecture modules, cmdlets, and scripts label Dec 14, 2016
joeyaiello added a commit to joeyaiello/joeyaiello that referenced this issue Dec 14, 2016
@joeyaiello
Copy link
Contributor

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. ls -la or rm -rf should just work on Linux boxes).

In this particular instance, unless we implement all the switches available to GNU which, we're going to get in trouble with people on the *nix side.

That being side, I believe we should eventually do some kind of module that gives PowerShell power users aliases like this.

@wpostma
Copy link
Author
wpostma commented Dec 15, 2016

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 which:

try  { Get-Command -Name which 
 } 
catch <#CommandNotFoundExeception#> { function which($name)
  {
     Get-Command -Name $name | Select-Object -ExpandProperty Definition
  }
 }

@DerpMcDerp
Copy link

The "see" command is more feature rich (and shorter to type too):

http://poshcode.org/5164

@wpostma
Copy link
Author
wpostma commented Dec 16, 2016

How is that command different than the built in Get-Command that my which function example has? I didn't see how it's called see from that code either?

@DerpMcDerp
Copy link

I didn't see how it's called see from that code either?

There is an alias up top:

New-Alias see Get-CommandDefinition

How is that command different than the built in Get-Command that my which function example has?

  1. see unrolls aliases automatically and tells you the name of the cmdlets and dlls they're in, e.g.
<#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>]
  1. see can tell you if the function is in a module, e.g.
<#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)

@mklement0 mklement0 mentioned this issue Jul 15, 2017
@iSazonov
Copy link
Collaborator
iSazonov commented Oct 8, 2017

It is dup #1975

@iSazonov iSazonov closed this as completed Oct 8, 2017
@iSazonov iSazonov added the Resolution-Duplicate The issue is a duplicate. label Oct 8, 2017
joeyaiello added a commit to joeyaiello/joeyaiello that referenced this issue May 28, 2018
joeyaiello added a commit to joeyaiello/joeyaiello that referenced this issue Dec 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution-Duplicate The issue is a duplicate. WG-DevEx-Portability authoring cross-platform or cross-architecture modules, cmdlets, and scripts
Projects
None yet
Development

No branches or pull requests

4 participants
0