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.
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
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.
Suppose you have an .EXE and you want to check if it has Command-Line Options. How can one know if the .EXE has this ability. In my case I know that Nir Sofers WebBrowserPassView.exe has the ability to start it via cmd.exe and WebBrowserPassView.exe /stext output.txt. But how can I find out if I don't know?
The easiest way would be to use use ProcessExplorer but it would still require some searching.
Make sure your exe is running and open ProcessExplorer.
In ProcessExplorer find the name of your binary file and double click it to show properties.
Click the Strings tab.
Search down the list of string found in the binary file. Most strings will be garbage so they can be ignored. Search for anything that might possibly resemble a command line switch.
Test this switch from the command line and see if it does anything.
Note that it might be your binary simply has no command line switches.
For reference here is the above steps applied to the Chrome executable. The command line switches accepted by Chrome can be seen in the list:
Invoke it from the shell, with an argument like /? or --help. Those are the usual help switches.
Sysinternals has another tool you could use, Strings.exe
Example:
strings.exe c:\windows\system32\wuauclt.exe > %temp%\wuauclt_strings.txt && %temp%\wuauclt_strings.txt
Just use IDA PRO (https://www.hex-rays.com/products/ida/index.shtml) to disassemble the file, and search for some known command line option (using Search...Text) - in that section you will then typically see all the command line options - for the program (LIB2NIST.exe) in the screenshot below, for example, it shows a documented command line option (/COM2TAG) but also some undocumented ones, like /L. Hope this helps?
Really this is an extension to Marcin's answer.
But you could also try passing "rubbish" arguments to see if you get any errors back. Getting any response from the executable directly in the shell will mean that it is likely looking at the arguments you're passing, with an error response being close to a guarantee that it is.
Failing that you might have to directly ask the publishers/creators/owners... sniffing the binaries yourself just seems like far too much work for an end-user.
Unless the writer of the executable has specifically provided a way for you to display a list of all the command line switches that it offers, then there is no way of doing this.
As Marcin suggests, the typical switches for displaying all of the options are either /? or /help (some applications might prefer the Unix-style syntax, -? and -help, respectively). But those are just a common convention.
If those don't work, you're out of luck. You'll need to check the documentation for the application, or perhaps try decompiling the executable (if you know what you're looking for).
This is what I get from console on Windows 10:
C:\>find /?
Searches for a text string in a file or files.
FIND [/V] [/C] [/N] [/I] [/OFF[LINE]] "string" [[drive:][path]filename[ ...]]
/V Displays all lines NOT containing the specified string.
/C Displays only the count of lines containing the string.
/N Displays line numbers with the displayed lines.
/I Ignores the case of characters when searching for the string.
/OFF[LINE] Do not skip files with offline attribute set.
"string" Specifies the text string to find.
[drive:][path]filename
Specifies a file or files to search.
If a path is not specified, FIND searches the text typed at the prompt
or piped from another command.
does anybody have idea why some windows XP installation would not evaluate path with double backslash in them?
Error is found on some XP (same build, patches, unknown more details). In most everything works, on some PCs following doesn't work:
Querying path (registry or folder) with functions like RegEnumKeyEx, fopen fails if path contains two backslashes, for example C:\\test\hello.txt.
strPath = "\SOFTWARE\Microsoft\Windows\Currentversion\run" // works
strPath = "\SOFTWARE\Microsoft\Windows\Currentversion\\run" // doesn't work
Is there some policy option or setting which can affect it?
Any help welcome,
RM
Why don't you simply modify the path to only have a single \ before using it?
Possibly completely unrelated, but in C/C++ (and other languages too) -
"c:\\\\test\hello.txt" is okay, but "c:\test\hello.txt" is not (because \t is parsed as a tab character, so you get a name that doesn't really exist).
Is there a chance the failure happens when the two backslashes don't exist, and things work when they do?