Create a file called Valid[File].txt and stick some text in it. Start powershell and go to the directory.
gc Valid[File].txt
should display the value in the file. It returns blank. If you use tab auto-completion it escapes the name:
gc 'Valid[File].txt'
but still returns nothing.
How do I reference files with brackets in their names?
Turns out the key was -literalpath. For details see this technet article
You probably need to enclose it in quotation marks: gc "Valid[File].txt"
Related
Here is a screen shot of the issue. You can see that I'm in a folder named C:\Test[ and I get an error when attempting to run Test.ps1 via a PowerShell command line:
Using an absolute file name doesn't make any difference:
I also tried escaping the bracket with a backtick, but had no luck with that.
Of course, in this simple example, I can just run .\Test.ps1 directly, but this is part of a bigger issue where a PowerShell script is run from an HTA which could be located in a folder that contains a left bracket, right bracket, or both. Different issues occur depending on the combination. It would be too confusing to show all permutations in one question, so I'm starting with this one, as it is the simplest to demonstrate.
My current "solution" is to display an error message if the user is attempting to run the HTA from a directory that contains left or right brackets, but I'd prefer to find a way to make it work.
I've read through various articles regarding square bracket folder names and PowerShell, but they all refer to using "-literalpath" or backticks within a PowerShell script and the only command line reference I found said to use "-file" which, of course, I'm already using.
That was this article:
Cannot run PowerShell script in folder with square braces
The answers provided in that article don't work for a folder with a single left bracket and actually don't really solve all issues for folders with a pair of brackets because even though "-file" allows the script to run, there will be further issues if there is a filename parameter passed to the script, but that's another issue. Let's see if we can just sort this single left bracket problem first.
Looks like that you can use the -InputFormat with the powershell command to help?
The brackets will need double backtick characters within the single quotes, the cat command only needed a single backtick like the cd command:
PS C:\> cat '.\Test`[\test.ps1'
echo "hello"
PS C:\> powershell -InputFormat "text" 'c:\test``[\test.ps1'
hello
Use ` before a bracket.
For example, I made a folder called hi[, now to go to that directory, use cd 'hi`[' and it will work.
Note: It only works with single quote ('), using double quotes (") throws an error
I have looked all about the web about powershell and path names with spaces, but nothing seems to work with this cmdlet.
My first argument doesn't have any spaces, but my second argument does:
Move-Item C:\Users\RB398970\Documents\WeekendUpdateReport\weekendCloseReport.pdf C:\Users\RB398970\Workspaces\Supply Chain\Document Templates\
I have tried surrounding the second argument with double quotes, with two sets of double quotes, with double quotes and nested single quotes, double quotes with single quotes in front of white spaces, using the ampersand in front, and multiple other things. None have worked.
I do know that the second argument is a valid path name - I can search it in my explorer and find the directory.
Any ideas?
Do you have access to the PowerShell ISE (integrated script editor)? What is helpful with it is that you can do script checking to insure that you have the quotes in the right locations, etc.
Either of these should work for you..
Move-Item 'C:\Users\RB398970\Documents\WeekendUpdateReport\weekendCloseReport.pdf' 'C:\Users\RB398970\Workspaces\Supply Chain\Document Templates\'
Move-Item "C:\Users\RB398970\Documents\WeekendUpdateReport\weekendCloseReport.pdf" "C:\Users\RB398970\Workspaces\Supply Chain\Document Templates\"
Hope this helps.
I believe I found the root issue. My problem was not that my file path contained spaces, but that my file path is one that my Windows Explorer shows as existing, yet does not actually have a local copy of. When searching for the second argument path in a DOS cmd window, it would not recognize it. That path is created by Sharepoint Workspace. I am not very familiar with the software, but my guess is that when it syncs with Shareoint, it does not store local files but contains references to where they are stored online. In any case, the lesson learned here is that if you are trying to use Sharepoint Workspace to update Sharepoint, it is complicated since it does not allow you to move files from a local machine to the software's workspace
****so this is how the bat file program look like and the error code i am geting ( click the drop box link/copy and paste to browser)****
https://www.dropbox.com/sh/6o4h666m0bwav69/AACTAbDe4jhyWdApEQOoAl7Na?dl=0
only program that is coming up is hitmanpro, every others get error
First of all, paste your code and error directly into your questions in the future.
Now then, the issue comes from the incorrect quotes being used. See how the first three pairs are kinda curly and the last ones are straight? Batch can't recognize curly quotes, probably because it's some Unicode thing. Always use straight quotes in batch. It's best if you code in notepad or a similar program; some text editors make the quotes curly automatically and call them "smart quotes."
When using the following script:
Run, *verb TargetFile
...Is there any way to make it work for verbs that contain a space? Simply writing it out as normal, the program interprets anything after the space as part of the target file. I've tried passing the verb as a variable, using double quotes in various spaces, but nothing seems to work.
Thanks.
Even though you said you had tried double quotes, here is an example that works with run and contains spaces:
Run "C:\Program Files\Internet Explorer\iexplore.exe" http://www.google.com
The most common use for a space in ahk is %A_Space%.
You could also try backtick s ('s btw I can't use backticks here, but they are below the ~ on a US keyboard). The use of 's is rare but has been shown to work in concatenation.
I am quite stuck; I need to compress the content of a folder, where I have multiple files (extension .dat). I went for shell scripting.
So far I told myself that is not that hard: I just need to recursively read the content of the dir, get the name of the file and zip it, using the name of the file itself.
This is what I wrote:
for i in *.dat; do zip $i".zip" $i; done
Now when I try it I get a weird behavior: each file is called like "12/23/2012 data102 test1.dat"; and when I run this sequence of commands; I see that zip instead of recognizing the whole file name, see each part of the string as single entity, causing the whole operation to fail.
I told myself that I was doing something wrong, and that the i variable was wrong; so I have replaced echo, instead than the zip command (to see which one was the output of the i variable); and the $i output is the full name of the file, not part of it.
I am totally clueless at this point about what is going on...if the variable i is read by zip it reads each single piece of the string, instead of the whole thing, while if I use echo to see the content of that variable it gets the correct output.
Do I have to pass the value of the filename to zip in a different way? Since it is the content of a variable passed as parameter I was assuming that it won't matter if the string is one or has spaces in it, and I can't find in the man page the answer (if there is any in there).
Anyone knows why do I get this behavior and how to fix it? Thanks!
You need to quote anything with spaces in it.
zip "$i.zip" "$i"
Generally speaking, any variable interpolation should have double quotes unless you specifically require the shell to split it into multiple tokens. The internal field separator $IFS defaults to space and tab, but you can change it to make the shell do word splitting on arbitrary separators. See any decent beginners' shell tutorial for a detailed account of the shell's quoting mechanisms.