Vista - Can not get content of some directory

Hello, I have a directory named C:\temp\[a] My problem is that I'm not
able to get content of the directory
Command dir 'C:\temp\[a]' doesn't work.
It doesn't write anything.
get-item c:\temp\[a] returns nothing

Any idea why?

use -LiteralPath option in Get-ChildItem and Get-Item cmdlets:

dir -LiteralPath C:\temp\[a]
gi -LiteralPath C:\Temp\[a]

--
WBR, Vadims Podans
PowerShell blog - www.sysadmins.lv

"stej" <cerna.zelva@xxxxxx> rakstīja ziņojum�
"news:30daec95-0fd7-444c-9976-aad2728d1ee9@xxxxxx"...

The reason its not working is the the [a] is being treated as a regular
expression. use -literal path as Vadims pointed out
--
Richard Siddaway
All scripts are supplied "as is" and with no warranty
PowerShell MVP
Blog: http://richardsiddaway.spaces.live.com/
PowerShell User Group: http://www.get-psuguk.org.uk


"Vadims Podans" wrote:

What surprised me was my inability to escape it or otherwise get around it
with quotes or back-ticks or whatever. The -literal is essential as far as I
can see.

--
Charlie.
http://msmvps.com/blogs/xperts64
http://mvp.support.microsoft.com/profile/charlie.russel

"RichS [MVP]" <RichSMVP@xxxxxx> wrote in message
news:761943F1-4AB8-4BEA-A547-2B3A7E77766E@xxxxxx

Hi, Charlie!

also you can escape it by doing this:

get-item c:\temp\[[]a[]]

you should put file name square brackets in to pattern brackets. Or can
escape it using 4 escape character:

get-item c:\temp\`````[a````]

this is neccessary if you use cmdlet that doesn't support -LiteralPath
switch. However here is mississue that you haven't any method to escape
brackets in Get-Acl/Set-Acl cmdlet (which doesn't support -LiteralPath
switch) using local path and you can escape brackets using examples above in
UNC paths. I wrote about escaping these characters in various scenarios at
my blog:

http://translate.google.com/translat...u&tl=en&swap=1
--
WBR, Vadims Podans
PowerShell blog - www.sysadmins.lv

"Charlie Russel - MVP" <charlie@xxxxxx> rakstīja ziņojum�
"news:OM#$p5ElJHA.4252@xxxxxx"...

I gave up before I reached four back ticks.

--
Charlie.
http://msmvps.com/blogs/xperts64
http://mvp.support.microsoft.com/profile/charlie.russel

"Vadims Podans" <vpodans> wrote in message
news:CB6E8BC5-C6AB-48FE-A2E4-4AC7B1E04CB0@xxxxxx

The problem with escaping is that you have to escape it to the WildCard
class, not to PowerShell, so even the [WildCard]::Escape() method
doesn't actually work.

It gets worse ... the syntax you have to use to set-content successfully
on such a file varies (in CTP3) depending on whether it already exists
or not -- and to all appearances -LiteralPath is broken in some of these
cmdlets in CTP3.

https://connect.microsoft.com/feedba...7243&SiteID=99

I had emails back and forth with Lee Holmes and Jeffrey Snover about
that bug (they had closed it) and Snover said it'll be fixed, but I
think you'll still need -Literal for anything with [] in the name.
Maybe you should file another bug against them for not using
-LiteralPath when you pipe files in. Eg: if you have a file structure
like this:

The whole thing is crazy though. I mean, if you set-location into a path
where there are [] in the path ... all the sudden you can't Set-Content
on anything that doesn't already exist?

ie:

mdkir '[c]' | cd
dir .. > upone.txt
set-content -lit upone.txt $(ls ..) ## this is ok
set-content -lit uptwo.txt $(ls ..\..) ## this is not
del *.* ## doesn't delete anything


Well, anyway. I rant. This is one of my pet-peaves right now, just
because it's such a weird and confusing behavior. Check this out:


## These are all errors, considered wildcard -- in piping?!!!?
## that's ridiculous, why would I want wilcard support here?
dir .. > 'up[1].txt'
dir .. > "up`[1`].txt"
dir .. > "up\[1\].txt"
## These create files with `[ in them...
dir .. > "up``[1``].txt"
dir .. > 'up`[1`].txt'
## and if I did all of this in my [c] directory ...
## This doesn't list that file I just made (it doesn't exist?)
ls up*
ls *.*
## This doesn't delete that file I just made (it doesn't exist?)
rm -lit 'up`[1`].txt'
rm *.*
rm *
ls | ... fullname | rm
## But miraculously, this works:
ls -filt up* | rm
## So does this, by the way:
ls | ... fullname | rm -lit {$_}


**Joel trails off ... **


Charlie Russel - MVP wrote:

Yeah, seems like a brain fart or something. I mean there's a reason why NTFS
doesn't allow ? and * in filenames... I don't think wildcards should be the
default for any of the content really other than get-childitem and even
then, they should stick to * and ? for wildcards unless a more sophisticated
pattern is needed in which case you could use a named parameter for that.

Josh

"Joel Bennett" <Jaykul@xxxxxx> wrote in message
news:e8c3TmFlJHA.4696@xxxxxx

I totally agree: other than Get-ChildItem, we don't need wildcard
support by default, and PERSONALLY I think we didn't need wildcard
characters that are legal parts of file names at all. Let us use an
alternate parameter that takes regex, and call it a day.
--
Joel

Josh Einstein wrote:

Oh, thanks to all of you. I'll try -literalPath. Before I gave up
escaping with 2 backticks. I'll have a look into Powershell in Action,
I obviously missed something. Thank you again.