locked
Question about Get-ChildItem -recurse -filter RRS feed

  • Question

  • Does anyone know why I can't get any results from Get-ChildItem from the root of a drive?

    gci 'C:\*.vbs' -recurse

    gci 'C:\*' -recurse -filter '.vbs'

    I'm trying to do the PowerShell equivalent of this:

    cmd.exe /c dir c:\*.vbs /s

     

    Wednesday, May 26, 2010 11:07 PM

Answers

  • Okay.

    gci 'C:\*.vbs' -recurse = find everything that ends in .vbs, and recurse through the subdirectories.  This will find any files in the root of c:\ that end in .vbs, and any directories that end in .vbs, and recursively list the contents of the directories.

    gci 'C:\*' -recurse -filter '.vbs' = find everything that is named (exactly) ".vbs", and if it is a directory, recurse through that directory.  This will find at most, either one file, or one directory named ".vbs" and if it is a directory recursivly list the contents of that directory.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
    • Proposed as answer by hoeyshane Monday, May 31, 2010 4:12 AM
    • Marked as answer by Steve Lynch 2 Wednesday, June 2, 2010 11:46 PM
    Thursday, May 27, 2010 12:07 AM
  • Well thanks for your replies and time, but I think I'll just give up on this and accept it the way it is without trying to understand why.  I've searched a few times and read several articles/blog posts but nothing really goes under the hood or explains why the parameters work exactly.  The get-help cmdlet is better than most scripting languages, but it still leaves a lot to be desired, and has lots of errors/confusing statements/ommissions.  For example:

    get-help get-childitem -full
    <snip>
        -Exclude <string[]>
            ... Wildcards are permitted.
    <snip>
            Accept wildcard characters?  false

    <snip>
        -Include <string[]>
            ... Wildcards are permitted.
    <snip>
            Accept wildcard characters?  false

     

    • Marked as answer by Steve Lynch 2 Wednesday, June 2, 2010 11:46 PM
    Saturday, May 29, 2010 8:51 PM

All replies

  • Try:

    gci c:\ -recurse -include *.vbs


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
    Wednesday, May 26, 2010 11:21 PM
  • Thanks, but I'm trying to figure out why the other examples I posted don't work.  I forgot to include the "-include" example that does work, sorry.
    Wednesday, May 26, 2010 11:27 PM
  • Okay.

    gci 'C:\*.vbs' -recurse = find everything that ends in .vbs, and recurse through the subdirectories.  This will find any files in the root of c:\ that end in .vbs, and any directories that end in .vbs, and recursively list the contents of the directories.

    gci 'C:\*' -recurse -filter '.vbs' = find everything that is named (exactly) ".vbs", and if it is a directory, recurse through that directory.  This will find at most, either one file, or one directory named ".vbs" and if it is a directory recursivly list the contents of that directory.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
    • Proposed as answer by hoeyshane Monday, May 31, 2010 4:12 AM
    • Marked as answer by Steve Lynch 2 Wednesday, June 2, 2010 11:46 PM
    Thursday, May 27, 2010 12:07 AM
  • So that basically makes sense, thanks.  Did you read that somewhere, or learn through trial and error, or just guessing? :)

    My original post was wrong, it had " -filter '.vbs' " but it should have had the asterisk wildcard " -filter '*.vbs' " and I would expect that to work the same as -include.  I'd just like to read something that explains why these return different results:

    gci 'c:\*' -recurse -filter '*.vbs'
    gci 'c:\*' -recurse -include '*.vbs'

    I remember reading somewhere that -filter is faster than -include, especially on slow or remote storage because -filter eliminates the results before they are returned from the provider, but -include returns all results from the provider and then does filtering.

    Just trying to learn PS better and avoid frustrations.

     

    Saturday, May 29, 2010 2:00 PM
  • Basically, it was a combination of experience, a quick perusal of

    get-help get-childitem -full | more

    and a couple of lines of testing.

    I can't give you an authoritative answer about the performance issues. but if an application demands performance optimization a few minutes at the command line with some test data and measure-command is usually a good investment.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
    Saturday, May 29, 2010 7:33 PM
  • Well thanks for your replies and time, but I think I'll just give up on this and accept it the way it is without trying to understand why.  I've searched a few times and read several articles/blog posts but nothing really goes under the hood or explains why the parameters work exactly.  The get-help cmdlet is better than most scripting languages, but it still leaves a lot to be desired, and has lots of errors/confusing statements/ommissions.  For example:

    get-help get-childitem -full
    <snip>
        -Exclude <string[]>
            ... Wildcards are permitted.
    <snip>
            Accept wildcard characters?  false

    <snip>
        -Include <string[]>
            ... Wildcards are permitted.
    <snip>
            Accept wildcard characters?  false

     

    • Marked as answer by Steve Lynch 2 Wednesday, June 2, 2010 11:46 PM
    Saturday, May 29, 2010 8:51 PM