[MSH] provider inconsistence with get-item / get-childitem

Discussion in 'Scripting' started by dreeschkind, Apr 6, 2006.

  1. dreeschkind

    dreeschkind Guest

    The following works within the FileSystem...

    ****************************************************************
    MSH C:\WINDOWS>gci (gi .)


    Directory: Microsoft.Management.Automation.Core\FileSystem::C:\WINDOWS


    Mode LastWriteTime Length Name
    ---- ------------- ------ ----
    ....
    ****************************************************************

    .... but not within the Registry ...

    ****************************************************************
    MSH HKLM:\SOFTWARE\Microsoft>gci (gi .)
    get-childitem : Cannot find path
    'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft'
    because it does not exist.
    At line:1 char:4
    + gci <<<< (gi .)
    MSH HKLM:\SOFTWARE\Microsoft>

    ****************************************************************

    I know the command doesn't make much sense like it is.
    I tracked this down when running a script I wrote for the FileSystem, that
    should also work with the Registry.
     
    dreeschkind, Apr 6, 2006
    #1
    1. Advertisements

  2. noticed this also:
    this is the good property

    gci (gi .).mshpath

    gr /\/\o\/\/
     
    /\\/\\o\\/\\/, Apr 6, 2006
    #2
    1. Advertisements

  3. dreeschkind

    dreeschkind Guest

    Yeah, just found out by myself :D
    Now my little script is provider independent!

    Here is another connected inconsistence:

    In the FileSystem the value of the .Name property of a container is just the
    name of the container, whereas the value of the .Fullname property is the
    path.

    ****************************************************************
    MSH C:\WINDOWS>(gi .).name
    WINDOWS
    MSH C:\WINDOWS>(gi .).fullname
    C:\WINDOWS
    ****************************************************************

    In the Registry the value of the .Name property is the path, whereas the
    ..Fullname property does not exist at all.

    ****************************************************************
    MSH HKLM:\SOFTWARE\Microsoft>(gi .).name
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
    MSH HKLM:\SOFTWARE\Microsoft>(gi .).fullname
    ****************************************************************

    Will this be fixed?
     
    dreeschkind, Apr 6, 2006
    #3
  4. dreeschkind

    applepwc Guest

    If you want to get the path info.Why not using this?
    (get-location).path
     
    applepwc, Apr 7, 2006
    #4
  5. With the FileSystem you are just getting lucky that the ToString() of a
    FileInfo or DirectoryInfo object looks like a drive-qualified MshPath. This
    is because we automatically mount drives for the FileSystem with the same
    names as the real file system drives. However for RegistryKey the
    ToString() is not a drive-qualified MshPath. It is the representation of
    the path understood by the provider (we call them provider-internal paths).
    Note how the error message doesn't include the drive name. As someone else
    pointed out use the MshPath property of the object returned from get-item.
     
    Jeff Jones [MSFT], Apr 7, 2006
    #5
  6. dreeschkind

    dreeschkind Guest

    Because get-location doesn't work with any path, it works only with the
    current location. My (get-item .) was just an example.
     
    dreeschkind, Apr 7, 2006
    #6
  7. dreeschkind

    dreeschkind Guest

    So, once again, will this be fixed?

    In the FileSystem the value of the .Name property of a container is just the
    name of the container, whereas the value of the .Fullname property is the
    path.

    ****************************************************************
    MSH C:\WINDOWS>(gi .).name
    WINDOWS
    MSH C:\WINDOWS>(gi .).fullname
    C:\WINDOWS
    ****************************************************************

    In the Registry the value of the .Name property is the path, whereas the
    ..Fullname property does not exist at all.

    ****************************************************************
    MSH HKLM:\SOFTWARE\Microsoft>(gi .).name
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
    MSH HKLM:\SOFTWARE\Microsoft>(gi .).fullname
    ****************************************************************
     
    dreeschkind, Apr 7, 2006
    #7
  8. We fixed this by extending the objects with properties that use the Msh
    prefix. We can't fix the underlying objects. That's why it was suggested
    to use the MshPath property. Also note that there is an MshChildName,
    MshIsContainer, MshDrive, MshProvider, and MshParentPath property on all
    these objects.
     
    Jeff Jones [MSFT], Apr 7, 2006
    #8
  9. The problem with fixing this is that both providers just expose the
    underlying .NET framework objects (DirectoryInfo, FileInfo and RegistryKey).

    One could argue that MSH should wrap all .NET framework objects, but part of
    the power is that MSH exposes the underlying objects.

    To get uniform behavior, use the Msh* properties (MshChildName, MshDrive,
    MshIsContainer, MshParentPath, MshPath and MshProvider):

    (gi .).mshchildname
    (gi .).mshpath
     
    Jouko Kynsijärvi, Apr 7, 2006
    #9
  10. dreeschkind

    dreeschkind Guest

    Oh, now I finally undestand the problem behind all that. The inconsistency
    is in the underlying .NET objects.

    Actually, MSH is my first contact with the .NET Framework and I don't know
    which objects existed before and which have been new introduced with MSH, so
    I'm sorry if I'm bugging too much and thanks again for providing
    clarification!
     
    dreeschkind, Apr 7, 2006
    #10
  11. All types introduced with MSH are in the System.Management.Automation
    namespace (or Microsoft.Management.Automation, but these are mostly
    internal), so you can figure out if a type...

    # is introduced with MSH
    (get-variable)[0].gettype().fullname
    System.Management.Automation.Variable

    # comes with .NET framework
    (gi c:\).gettype().fullname
    System.IO.DirectoryInfo
     
    Jouko Kynsijärvi, Apr 7, 2006
    #11
  12. Actually, one of the things that I'm tickled about is how good a tool MSH
    will be as a .NET teaching tool. You can really discover alot about the
    frameworks with MSH!

    Ask away!

    jim

    --
    James W. Truher [MSFT]
    Monad Program Management
    Microsoft Corporation
    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    James Truher [MSFT], Apr 8, 2006
    #12
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.