none
Get-ChildItem files, includes, literalpath and square brackets

    Question

  • It seems like I'm dealing with a worst case scenario for GCI here. I'm trying to create a foreach loop to rename files with specific extensions after the folder in which they reside. However, I don't seem to be able to successfully return the list of files I want to change, correctly. The extra challenge here is that there are square brackets in the folder names.

    The closest I've managed is:

    gci -File -include('*.jpg','*.jpeg','*.png','*.gif') -Recurse -LiteralPath ".\Test `[blah`]\"

    This almost works, but I end up getting all of the files; the Include doesn't seem to work. I've read this might be a side effect of  the way the filter works, and appending a * to the Path might return the filtered collection I want. Except that the square brackets in the folder name appear to break gci if I don't use -LiteralPath, and -LiteralPath means I can't append the * and have it expand as wildcard properly.

    So....I'm out of ideas at the moment. It's starting to feel like maybe I'll have to apply another filter on a return set of all the files, and just live with it, but I'm hoping someone can show me something I missed to return just the file set I want.

    Hopefully I explained that in an way that is understandable.

    Thank you!

    Thursday, June 14, 2018 5:48 PM

Answers

  • You should never use those characters in a folder name.  They cannot be escaped.


    \_(ツ)_/

    if they should never be used, the should be disallowed in the file system, just like ?, *, and a number of others. Powershell being unable to cope with them well is a terrible reason to not use a character allowed by the file sytem. What if it couldn't handle the letter S?

    But at least that tells me there's not a simple workaround. I ended up adding a switch statement and just processing the extensions myself, it works well enough and is fast enough it's not an issue.

    Thanks

    14 minutes ago

All replies

  • Get-ChildItem  .\Test\blah -include *.jpg,*.jpeg,*.png,*.gif -File -Recurse

    \_(ツ)_/


    Thursday, June 14, 2018 6:36 PM
    Moderator
  • That's not my path though. There are square brackets in the folder name, hence the need for -LiteralPath.

    The rest of that would imply the order of the switches matters? As does specifying the -Include items in parens vs just as a comma separated list?

    Friday, June 15, 2018 3:57 PM
  • You should never use those characters in a folder name.  They cannot be escaped.


    \_(ツ)_/

    Friday, June 15, 2018 6:00 PM
    Moderator
  • How about instead of -include:

     | where name -match 'jpg$|jpeg$|png$|gif$'



    • Edited by JS2010 Friday, June 15, 2018 11:37 PM
    • Proposed as answer by jrvModerator Saturday, June 16, 2018 9:36 PM
    Friday, June 15, 2018 11:37 PM
  • How about instead of -include:

     | where name -match 'jpg$|jpeg$|png$|gif$'



    The "Include" works fine.  It is the incorrect path characters that are the issue.


    \_(ツ)_/

    Friday, June 15, 2018 11:53 PM
    Moderator
  • I disagree.  -include in PS 5 only works if there's a wildcard in the path, or with the -recurse option.  It's resolved in PS 6.

    Saturday, June 16, 2018 9:06 PM
  • I disagree.  -include in PS 5 only works if there's a wildcard in the path, or with the -recurse option.  It's resolved in PS 6.

    Yes which is why we add the options.  If we use a post filter (Where) the performance will be very bad on large file systems.

    The real issue here is the illegal characters in the path name.


    \_(ツ)_/

    Saturday, June 16, 2018 9:26 PM
    Moderator
  • Using the "Where" may be the only solution.


    \_(ツ)_/

    Saturday, June 16, 2018 9:34 PM
    Moderator
  • Yes - This does seem to work in all cases:

    Get-Item d:\test?junk?1\* | where{$_.Extension -match 'ps1|txt'}


    \_(ツ)_/

    Saturday, June 16, 2018 9:36 PM
    Moderator
  • You should never use those characters in a folder name.  They cannot be escaped.


    \_(ツ)_/

    if they should never be used, the should be disallowed in the file system, just like ?, *, and a number of others. Powershell being unable to cope with them well is a terrible reason to not use a character allowed by the file sytem. What if it couldn't handle the letter S?

    But at least that tells me there's not a simple workaround. I ended up adding a switch statement and just processing the extensions myself, it works well enough and is fast enough it's not an issue.

    Thanks

    14 minutes ago

  • The real issue here is the illegal characters in the path name.


    \_(ツ)_/

    There's nothing illegal about the characters. They are perfectly fine in NTFS. They are perfectly fine in File Explorer. The problem is Powershell can't manage them. Don't blame a weakness of Powershell on the file system.

    11 minutes ago