Windows Vista Forums

Suggestion: Implicit invocation should work with non-Filesystem items

  1. #1


    Alex K. Angelopoulos [MVP] Guest

    Suggestion: Implicit invocation should work with non-Filesystem items

    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.



      My System SpecsSystem Spec

  2. #2


    dreeschkind Guest

    RE: Suggestion: Implicit invocation should work with non-Filesystem it

    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.
    >
    >
    >


      My System SpecsSystem Spec

  3. #3


    Alex K. Angelopoulos [MVP] Guest

    Re: Suggestion: Implicit invocation should work with non-Filesystem it

    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.
    >>
    >>
    >>




      My System SpecsSystem Spec

Suggestion: Implicit invocation should work with non-Filesystem items

Similar Threads
Thread Forum
some of the start menu items don't work!
Please help! Under Vista SP1, I click the "Microsoft Office Word 2007" item in start menu, and it can't launch the app!!! Nothing happens. The...
Vista General
implicit/explicit data type conversion?
I'm comparing a couple integers whose values fall in the range of 1 - 100 as follows: if($guess -lt $number) { blah blah blah... } elseif($guess...
PowerShell
Remote invocation of ps commands?
We have a client-server application which can also be called from the command line, its first cmd line arg is the ip address of the server. ...
PowerShell
Function names and invocation
function get-ComRSS { param($param1) $param1 $param1 } comrss test1 Why is it that the script above runs to completion without error?
PowerShell
Intercepting WCF method invocation
Hello all, We need to execute some code after a WCF method has finished and its reply message is prepared. The last thing we tried was to use an...
Indigo
Suggestion: I submitted a suggestion for a Generic Soap Cmdlet via Connect. Please check it out and vote.
Please review the request and make comments. If this is something you think would be usefully. Please vote for it. Jeffrey says Voting does make a...
PowerShell
COM IDispatch and Powershell invocation
Can Powershell handle COM invocation with Object implementing Idispatch interfaces. I would think so, however why can I run a piece of script via...
PowerShell