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

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.

 

noticed this also:
this is the good property

gci (gi .).mshpath

gr /\/\o\/\/

 

Yeah, just found out by myself
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?

 

If you want to get the path info.Why not using this?
(get-location).path

 

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.

 

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

 

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

 

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.

 

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

 

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!

 

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

 

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.