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.   


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

  4. #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! Vista General
implicit/explicit data type conversion? PowerShell
Remote invocation of ps commands? PowerShell
Function names and invocation PowerShell
Suggestion: I submitted a suggestion for a Generic Soap Cmdlet via Connect. Please check it out and vote. PowerShell