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
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 am writing an mIRC script for a bot account to read a random line of text from a text file when a user keys in !read. As of now, when any user types !read, absolutely nothing happens. I have other commands set to work on TEXT commands, but this one seems to be the most puzzling, as I'm referencing a document rather than putting everything into the script itself.
on *:TEXT:!text:#: {
$read(C:\Program Files (x86)\mIRC\8Ball.txt,n)
}
My file is titled 8Ball.txt. What could be going wrong here?
Got it.
echo -a $read(C:\Users\Christopher\Desktop\8Ball.txt,n)
Changing the directory ended up doing it...it wasn't liking the location for some reason...I either blame me putting a / in front of echo, or I blame the space in Program Files (x86)
Your best move is to use the relative mIRC dir identifier $mircdir combing it with $qt which adds enclosing quotes.
$qt($+($mircdir,8Ball.txt))
Output:
"C:\Program Files (x86)\mIRC\8Ball.txt"
This way, you won't need to wonder why the script break when you changed the mIRC directory a year after.
I have an executable in a directory that is versioned, so the directory changes when the tool is updated.
The current command I run is the following:
.\packages\Chutzpah.4.1.0\tools\chutzpah.console.exe .\Tests\chutzpah.json
I want to do something like the following:
.\packages\Chutzpah**\tools\chutzpah.console.exe .\Tests\chutzpah.json
Windows command line doesn't like to expand wildcards but I'm hoping this is possible with powershell.
Simple answer here could be to use resolve-path which
Resolves the wildcard characters in a path, and displays the path contents.
So in practice you should be able to do something like this.
$path = Resolve-Path ".\packages\Chutzpah**\tools\chutzpah.console.exe" -Relative
& $path ".\Tests\chutzpah.json"
Note that Resolve-Path has the potential to match more that one thing.
Actually, Windows will expand the wild cards, but if the non-wildcard portion is not unique, you'll get the (I think) FIRST match.
So I think that really your problem is
"How do I tell which version I should be executing"
Which, if you have project files, etc., you might be able to extract from there.
In fact, you might well be wanting to extract something from the solution packages.config file, assuming that the .\packages\ prefix is there because you are wanting to run tests against files that are in a NuGet package.
Can you supply some more details?
EDIT:
OK, so you probably need to do something like System.IO.Directory.GetDirectories(path, pattern)
https://msdn.microsoft.com/en-us/library/6ff71z1w(v=vs.110).aspx
And depending on what you'd done with "Chutzpah" you'll get one or more matches that you could use to select the correct path.
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.