Inconsistency between get-childitem -include and -exclude parameters

Question

Hi,
Powershell 2.0
Does anyone else consider this a minor design bug in the Get-ChildItem command?  
# create dummy files
"a","b","c" | % {$null | out-file "c:\temp\$_.txt"}
# this "fails", returns nothing
get-childitem c:\temp -include a*,b*
# this "works", returns desired files
get-childitem c:\temp\* -include a*,b*
# this "works", excludes undesired files
get-childitem c:\temp -exclude a*,b*
# this "fails", excludes undesired files BUT RECURSES sub-directories
get-childitem c:\temp\* -exclude a*,b*
I'm writing a wrapper script around the GCI cmdlet, but the inconsistency between the two parameters is problematic.  My end user will surely just type a path for the path parameter, then wonder why -include returned nothing.  I can't unconditionally
add an asterisk to the path parameter, since that messes up the exclude output.
I'm just wondering why Microsoft didn't make the parameter interaction consistent???  
# includes desired files in the specified path
get-childitem -path c:\temp -include a*,b*
# excludes undesired files in the specified path
get-childitem -path c:\temp -exclude a*,b*
# combine both options
get-childitem -path c:\temp -include a*,b* -exclude *.log,*.tmp
# same as above, the asterisk doesn't matter
get-childitem -path c:\temp\* -include a*,b*
get-childitem -path c:\temp\* -exclude a*,b*
get-childitem -path c:\temp\* -include a*,b* -exclude *.log,*.tmp
# same as above, but explicitly recurse if that's what you want
get-childitem -path c:\temp\* -include a*,b* -recurse
get-childitem -path c:\temp\* -exclude a*,b* -recurse
get-childitem -path c:\temp\* -include a*,b* -exclude *.log,*tmp -recurse
If I execute the "naked" get-childitem command, the asterisk doesn't matter...
# same results
get-childitem c:\temp
get-chileitem c:\temp\*
If this isn't considered a bug, can you explain why the inconsistency between the two parameters when combined with the -path parameter?
Thanks,
Scott

Answer 1

The Get-ChildItem cmdlet syntax is horrific for advanced use. It's not a bug in the classic sense, so you shouldn't call it that. However, feel free to call it awful, ugly, disastrous, or any other deprecatory adjective you like - it really is
nasty.
Get-ChildItem's unusual behavior is rooted in one of the more 'intense' dialogues between developers and users in the beta period. Here's how I recall it working out; some details are a bit fuzzy for me at this point.
Get-ChildItem's original design was as a tool for enumerating items in a namespace -
similar to but not equivalent to dir and
ls. The syntax and usage was going to conform to standard PowerShell (Monad at the time) guidelines.
In a nutshell, what this means is that the Path parameter would have truly just meant Path - it would not have been usable as a combination path specification and result filter, which it is now. In other words
(1) dir c:\temp
means you wanted to return children of the container c:\temp
(2) dir c:\temp\*
means you wanted to return children of all containers inside
c:\temp. With (2), you would never get c:\tmp\a.txt returned, since a.txt is not a container.
There are reasons that this was a good idea. The parameter names and filtering behavior was consistent with the evolving PowerShell design standards, and best of all the tool would be straightforward to stub in for use by namespace
providers consistently.
However, this produced a lot of heated discussion. A rational, orthogonal tool would not allow the convenience we get with the dir command for doing things like this:
(3) dir c:\tmp\a*.txt
Possibly more important was the "crash" factor.  It's so instinctive for admins to do things like (3) that our fingers do the typing when we list directories, and the instant failure or worse, weird, dissonant output we would get with a more pure Path
parameter is exactly like slamming into a brick wall.
At this point, I get a little fuzzy about the details, but I believe the Get-ChildItem syntax was settled on as a compromise that wouldn't derail people expecting files when they do (3), but would still allow more complex use.  I think that this
is done essentially by treating all files as though they are containers for themselves. This saves a lot of pain in basic use, but introduces other pain for advanced use.
This may shed some light on why the tool is a bit twisted, but it doesn't do a lot to help with your particular wrapping problem. You'll almost certainly need to do some more complicated things in attempting to wrap up Get-ChildItem. Can you describe some
details of what your intent is with the wrapper? What kind of searches by what kind of users, maybe? With those details, it's likely people can point out some specific approaches that can give more consistent results.