Can someone possibly explain the difference between "get-childitem" and "get-childitem *". Both seem to return the same items if you just let powershell format the result. However when I issued the following with my current location pointing to c:\

PS C:\> "$((get-childitem)[23])"
WINDOWS
PS C:\> "$((get-childitem *)[23])"
C:\WINDOWS
PS C:\>
 
note: the 23 subscript just happens select the WINDOWS directory on my system at present.

So it seems that one seems to return the selected items name while the other returns its fullname.

 Note however no problem with these:

PS C:\> "$((get-childitem)[23].name)"
WINDOWS
PS C:\> "$((get-childitem *)[23].name)"
WINDOWS
PS C:\> "$((get-childitem)[23].fullname)"
C:\WINDOWS PS
C:\> "$((get-childitem *)[23].fullname)"
C:\WINDOWS PS C:\>

Maybe this is a clue:
PS C:\> "$((get-childitem)[23].tostring())"
WINDOWS PS
C:\> "$((get-childitem *)[23].tostring())"
C:\WINDOWS PS C:\>

Since it seems to have the same behaviour as my original example and it makes sense that "tostring()" might to used to deal with the fact that I'm interpolating something more complex than a simple string.  But how would the lack or presence of the asterisk effect the result of get-childitem in such a fashion especially considering that I think I even got the same types back for the result when I examined with ".gettype".


For the record  I am trying this with powershell 2.0 ctp3.   I don't have older versions to try this with.

Well my first idea is that by default Get-ChildItem defaults to the current container, but when you use * you explicitly tell it to work with the *contents* of the container instead of the container itself. It is a subtle distinction and I'm not positive why it causes the behavior that you see, but I think it does.

Best educated guess:

When you use a wildcard in the path parameter in Get-ChildItem, you may end up with objects (files and folders) from multiple directories. For example, if you have this structure:

C:\Temp1\Folder1
C:\Temp2\Folder1
C:\Temp2\Folder2

You could do this:

gci C:\Temp*\Folder1

Converting those items to a string without the path would not be very useful because they are in different locations.

On the flipside, if you run Get-ChildItem without a wildcard and optionally with the filter parameter, you are working within one folder and therefore the string representation does not need the path to qualify the items.

Not necessarily the right thing to do for everyone, but that's my take on why it works that way.

Get-ChildItem -Filter * returns a short name.  Maybe that's where you saw the short name while using a wildcard?

Based on that idea and some non-Powershell shell experience I tried:

get-childitem .

And that seems to give me the short name.

Then I tried:

get-childitem */*

That was quite interesting.  Very reminiscent of a (Dos) DIR /S

Not exactly what I'd expect though from something that is going to send a bunch of file and dir info objects down a pipe.  I would have expected a single list of files (and dirs) possibly with fullnames to make them unique ( a bit like "find ." in some other shells). So is all the impressive subdirectory titling that appears when you leave powershell format the results all being done at the tail end of the pipe by a very smart default formatting routine?

To add to the confusion, in a few of my recent experiments I have seen cases where "get-childitem *"  is returning a short name but I've not managed as of yet to determine what was so special in that case.

 

Don't think I was using -filter since I wasn't aware of it at the time. More likely I got confused with all the tests I was making.