https://connect.microsoft.com/feedba...8556&SiteID=99

At present, you can only invoke items directly by path if they are accessed
via a FileSystem-provided PSDrive.

Extending implicit invocation to other providers - and giving guidance for
it - will give us simple, intuitive methods to access specific functionality
that also allows us to do things we cannot explicitly do at present. Here's
a rough outline of how the concept would work.



When a provider is implemented, guidance should suggest supporting
invocation as well. Invocation would 'run' the item in a way that is
sensible, logical, and useful. For existing providers (and some theoretical
ones) it might make sense to have the following happen.

Function PSProvider:
Execute the function. You could then explicitly specify function:\more and
be guaranteed to get function:\more or - if it had been removed - nothing.
This would be exactly analogous to explicitly specifying a commandline
executable by path.

Alias PSProvider:
If alias:\gcm is specified, behavior will be identical to specifying just
gcm. I'm not sure about the usefulness of this given that aliases are always
resolved first; it would just be consistent.

Theoretical - Cmdlet PSProvider and Script PSProvider:
If providers for seeing scripts and cmdlets analogously to functions are
ever implemented, they should also behave the same way. One could then, for
example, get identical results from each of the following:
cmdlet:\Get-Command cmdlet:\Get-Command -Usage
cmdlet:\Get-Command Get-Command -Usage
Get-Command Get-Command -Usage

Variable and Environment PSProviders:
Possibly behaves as Get-Item?
This should simply return the value of the specific variable, precisely as
direct use of the variable does. I'm not sure what the use would be for this
specifically, although it would be consistent and intuitive.
We already have something roughly similar in that items can be found in
these providers like this:
$envath returns the path
$variableshome returns the pshome path
By extending invocation, the following would be equivalent:
env:\path would do the same thing as $envath
variable:\pshome would do the same thing as $variableshome

Certificate and Registry PSProviders
Possibly behaves as Get-Item?
Specifying a registry or certificate item by path would probably be best
treated as meaning to return the specific certificate or key.

I think this has already been suggested:

https://connect.microsoft.com/feedba...7319&SiteID=99

--
greetings
dreeschkind


"Alex K. Angelopoulos [MVP]" wrote:

> https://connect.microsoft.com/feedba...8556&SiteID=99
>
> At present, you can only invoke items directly by path if they are accessed
> via a FileSystem-provided PSDrive.
>
> Extending implicit invocation to other providers - and giving guidance for
> it - will give us simple, intuitive methods to access specific functionality
> that also allows us to do things we cannot explicitly do at present. Here's
> a rough outline of how the concept would work.
>
> When a provider is implemented, guidance should suggest supporting
> invocation as well. Invocation would 'run' the item in a way that is
> sensible, logical, and useful. For existing providers (and some theoretical
> ones) it might make sense to have the following happen.
>
> Function PSProvider:
> Execute the function. You could then explicitly specify function:\more and
> be guaranteed to get function:\more or - if it had been removed - nothing.
> This would be exactly analogous to explicitly specifying a commandline
> executable by path.
>
> Alias PSProvider:
> If alias:\gcm is specified, behavior will be identical to specifying just
> gcm. I'm not sure about the usefulness of this given that aliases are always
> resolved first; it would just be consistent.
>
> Theoretical - Cmdlet PSProvider and Script PSProvider:
> If providers for seeing scripts and cmdlets analogously to functions are
> ever implemented, they should also behave the same way. One could then, for
> example, get identical results from each of the following:
> cmdlet:\Get-Command cmdlet:\Get-Command -Usage
> cmdlet:\Get-Command Get-Command -Usage
> Get-Command Get-Command -Usage
>
> Variable and Environment PSProviders:
> Possibly behaves as Get-Item?
> This should simply return the value of the specific variable, precisely as
> direct use of the variable does. I'm not sure what the use would be for this
> specifically, although it would be consistent and intuitive.
> We already have something roughly similar in that items can be found in
> these providers like this:
> $envath returns the path
> $variableshome returns the pshome path
> By extending invocation, the following would be equivalent:
> env:\path would do the same thing as $envath
> variable:\pshome would do the same thing as $variableshome
>
> Certificate and Registry PSProviders
> Possibly behaves as Get-Item?
> Specifying a registry or certificate item by path would probably be best
> treated as meaning to return the specific certificate or key.
>
>
>

Yes, and I just rated it a 5.

"dreeschkind" <dreeschkind@discussions.microsoft.com> wrote in message
news:882120EF-C9A5-4CC3-AF1E-88FBFE24DE9C@microsoft.com...
>I think this has already been suggested:
>
> https://connect.microsoft.com/feedba...7319&SiteID=99
>
> --
> greetings
> dreeschkind
>
>
> "Alex K. Angelopoulos [MVP]" wrote:
>
>> https://connect.microsoft.com/feedba...8556&SiteID=99
>>
>> At present, you can only invoke items directly by path if they are
>> accessed
>> via a FileSystem-provided PSDrive.
>>
>> Extending implicit invocation to other providers - and giving guidance
>> for
>> it - will give us simple, intuitive methods to access specific
>> functionality
>> that also allows us to do things we cannot explicitly do at present.
>> Here's
>> a rough outline of how the concept would work.
>>
>> When a provider is implemented, guidance should suggest supporting
>> invocation as well. Invocation would 'run' the item in a way that is
>> sensible, logical, and useful. For existing providers (and some
>> theoretical
>> ones) it might make sense to have the following happen.
>>
>> Function PSProvider:
>> Execute the function. You could then explicitly specify function:\more
>> and
>> be guaranteed to get function:\more or - if it had been removed -
>> nothing.
>> This would be exactly analogous to explicitly specifying a commandline
>> executable by path.
>>
>> Alias PSProvider:
>> If alias:\gcm is specified, behavior will be identical to specifying just
>> gcm. I'm not sure about the usefulness of this given that aliases are
>> always
>> resolved first; it would just be consistent.
>>
>> Theoretical - Cmdlet PSProvider and Script PSProvider:
>> If providers for seeing scripts and cmdlets analogously to functions are
>> ever implemented, they should also behave the same way. One could then,
>> for
>> example, get identical results from each of the following:
>> cmdlet:\Get-Command cmdlet:\Get-Command -Usage
>> cmdlet:\Get-Command Get-Command -Usage
>> Get-Command Get-Command -Usage
>>
>> Variable and Environment PSProviders:
>> Possibly behaves as Get-Item?
>> This should simply return the value of the specific variable, precisely
>> as
>> direct use of the variable does. I'm not sure what the use would be for
>> this
>> specifically, although it would be consistent and intuitive.
>> We already have something roughly similar in that items can be found in
>> these providers like this:
>> $envath returns the path
>> $variableshome returns the pshome path
>> By extending invocation, the following would be equivalent:
>> env:\path would do the same thing as $envath
>> variable:\pshome would do the same thing as $variableshome
>>
>> Certificate and Registry PSProviders
>> Possibly behaves as Get-Item?
>> Specifying a registry or certificate item by path would probably be best
>> treated as meaning to return the specific certificate or key.
>>
>>
>>