BUGBUG: Get-Command ordering is useless ...

Get-Command outputs FUNCTIONs before ALIASes, despite the fact that
aliases take precedence when executing.

[152]> Get-Command help

CommandType Name
Definition
----------- ----
----------
Function help
write-host 'function' -fore cyan
Alias help
Get-PagedHelp
Application help.exe C:
\Windows\system32\help.exe
ExternalScript Help.ps1 C:
\Help.ps1


I've written myself a little script which ... I think ... has the
right order (I've never seen a "Script" object that wasn't an
ExternalScript), but really Get-Command ought to output them in the
correct order. Does anyone have a *deffinitive* list of the
ordering? For the sake of your memory, here's the list of command
types, in the order I think is correct:

Alias | Function | Filter | Cmdlet | Script | Application |
ExternalScript

Oh, and here's the script, for arguments sake

## This ought to be the same as Get-Command, except...
## This Which function will output the commands ...
## in the actual order they would be used by the shell
function which( [string]$command ) {
# aliases, functions, cmdlets, scripts, executables, normal files
# Alias | Function | Cmdlet | Script | Application
$Script:ErrorActionPreference = "SilentlyContinue"
Get-Command $command -commandType Alias
Get-Command $command -commandType Function
Get-Command $command -commandType Cmdlet
Get-Command $command -commandType Script
Get-Command $command -commandType Application
Get-Command $command -commandType ExternalScript
}

Is this the right order?
[enum]::getNames('System.Management.Automation.CommandTypes')

--
Kiron

On Nov 8, 2:31 pm, "Kiron" <Ki...@xxxxxx> wrote: Nope. Applications get run before External scripts (I tested that one
earlier)

You know ... another problem is that Get-Command sometimes just ...
doesn't work the way you would expect it to:

Get-Command Process

Tried with wildcards?

Get-Command *Process*

Thanks for sharing your script.

--
Kiron

<Jaykul@xxxxxx> wrote in message
news:1194549063.722867.178840@xxxxxx <snip>

That's unfortunate. I have been under the impression that GCM listed
commands in order of execution precedence. Submit a bug, post the link here
and I'll vote on it.

--
Keith

On Nov 8, 2:55 pm, "Kiron" <Ki...@xxxxxx> wrote: Sure, but again ... Get-Command *Process returns not just out-of order
results, but actually different commands with no way of telling which
is it that would run when you execute "Process" (by itself, and
without quotes) in the shell -- which DOES work. My point is:
"Process" is a command that works in the shell at the command line and
in script ... but which Get-Command can't even find. (Process
resolves invisibly to Get-Process, as you can tell by executing
"process -?" but Get-Command has no clue about that, apparently --
which is potentially very frustrating for a user who's trying to
understand someone's code ...

Hi Joel,

This is really interesting. I didn't know that you could call the get-
cmdlets without specifying get-. Looking at this thread I thought your
command precedence list was accurate, but when I execute "service" by itself
it doesn't give me what I would expect. I thought it would execute
get-service, but instead it executes service.exe, a program that is in my
path. That would seem to imply that applications take precedence before
cmdlets if you're calling them via this undocumented method, but they take
precedence after cmdlets if you're calling them via the full name or an
alias. I think this "feature" is an undocumented last resort name
resolution step used to help resolve command names. Although even as a last
resort, one might expect get-command to find it however if you look at the
results from get-command, every object returned has an exact name match of a
command you can execute (minus the extension for applications, although you
can specify a filename with extension in get-command and that will work as
well). If get-command starts supporting partial name matches just because
the PowerShell engine has this last resort name resolution method "feature",
where do you draw the line?

Personally, I think the fix should be that if get- cmdlets are to be able to
function this way it should be via a defined alias, not via a last resort
name resolution step that doesn't fit well into PowerShell in all places as
you have demonstrated here.

With respect to the get-command ordering, I'll support that if you log it on
the connect site as well.

--
Kirk Munro
Poshoholic
http://poshoholic.com


"Joel Jaykul Bennett" <Jaykul@xxxxxx> wrote in message
news:1194586361.314549.211570@xxxxxx

On Nov 9, 10:20 am, "Kirk Munro" <so...@xxxxxx> wrote: Yep, Joel and I discussed this on IRC ( #powershell on freenet ), and
I suggested that an example of how this just feels wrong is:

ps > command command

....e.g. command would fail to find itself (if it didn't decide to load
the 16bit command.com first!).

Yuck.

- Oisin

Regarding calling command command, that's more fuel for the fire for this
"backdoor" method of calling get- cmdlets being replaced by properly defined
aliases.

And the workaround to this issue is to put this in your profile:

Get-Command -Verb Get | ForEach-Object {
if ((Get-Alias $_.Noun -ErrorAction SilentlyContinue) -eq $null) {
New-Alias $_.Noun $_.Name
}
}

--
Kirk Munro
Poshoholic
http://poshoholic.com


"Oisin Grehan" <oising@xxxxxx> wrote in message
news:1194623352.733303.310010@xxxxxx

On Nov 9, 10:20 am, "Kirk Munro" <so...@xxxxxx> wrote:
Personally, I would draw the line at "Get-Command should use the same
command-resolution as the shell"

I don't disagree that the automatic verb inference is problematic ...
especially since (as you point out) it gets resolved only as a last
resort (when nothing would be returned from Get-Command <noun>), but
as long as it's there, I think Get-Command should be able to figure it
out.
https://connect.microsoft.com/feedba...9558&SiteID=99

I wasn't sure if they're even using connect anymore, since there's
*nothing* on the PowerShell connect page since the RC2 of PowerShell
1.0 ... https://connect.microsoft.com/site/s...aspx?SiteID=99