The following, which includes one of the things you tried, should work, but currently[1] doesn't work due to a bug:
# SHOULD work, but CURRENTLY BROKEN:
Get-ChildItem *``[* # 1st ` is for string parsing, 2nd ` for wildcard escaping
Get-ChildItem "*``[*" # ditto, with double quotes
Get-ChildItem '*`[*' # single-quoted alternative, requires only 1 `
Note that the use of a (the first) positional argument implicitly binds to Get-ChildItem
's -Path
parameter.
The intent is for Get-ChildItem
to see the following literal after argument parsing: *`[*
, which correctly escapes [
with `
in order to treat it as a literal.
As an aside: unquoted *`[*
is equivalent to double-quoted "*`[*"
, which results in literal *[*
, because PowerShell's string parsing interprets the `
and effectively removes it.
Workarounds:
Instead of escaping the [
character, enclose it in [...]
, a character-set expression, which causes it to be matched literally:
Get-ChildItem *[[]* # OK
Interestingly, performing the filtering via -Include
does not exhibit the bug:
Get-ChildItem * -Include '*`[*' # OK
Another option is to use -Filter
instead of (implied) -Path
, as demonstrated in Paxz's answer, but note that -Filter
's wildcard language is not the same as PowerShell's (as supported by the -Path
and -Include
/ -Exclude
parameters); the -Filter
argument is passed to the Windows API, whose wildcard language differs as follows:
- It supports fewer constructs, notably no character sets or ranges (
[...]
).
- It has legacy quirks - see this answer.
- On the plus side, use of
Filter
, due to filtering at the source, performs better than letting PowerShell do the filtering via (implied) -Path
or -Include
.
Yet another option would be to add another layer of escaping, but that is ill-advised, because it will stop working once the bug is fixed:
# NOT RECOMMENDED: will stop working once the bug is fixed.
Get-ChildItem '*``[*'
[1] As of Windows PowerShell v5.1 / PowerShell Core 6.2.0-preview.3