Just to provide some lessons to this thread and explain where other attempts went wrong...
Assuming <curitem> = D:\test.txt
Code: Select all
run "c:\Programas\Sandboxie\start.exe" RunDLL32.EXE SHELL32.DLL,OpenAs_RunDLL <curitem>;
Parsed & Resolved:
run
----
"c:\Programas\Sandboxie\start.exe" RunDLL32EXE SHELL32DLL
----
OpenAs_RunDLL D:\test.txt
The problem here is XY is attempting to guess where the first parameter of run ends. Outside of a quoted string the periods and comma signify concatenation and parameter delimiter respectively. Hence the resolved command removes the periods in RunDLL32.exe and Shell32.dll, and treats OpenAs... as your input for run's directory parameter.
Code: Select all
run ""c:\Programas\Sandboxie\start.exe" "RunDLL32.EXE SHELL32.DLL,OpenAs_RunDLL <curitem>";
Parsed & Resolved:
run
----
exe" "RunDLL32EXE SHELL32DLL
----
OpenAs_RunDLL D:\test.txt";
This one really throws XY for a loop. The "" at the start opens and closes a string. The C:\... isn't in the string, then the period in start.exe tells XY to concatenate strings, " " is another string, and RunDLL... is outside of the string. It's just terribly malformed, and as you'll notice stepping through it causes a number of overflow errors as XY tries to figure it out.
Code: Select all
run '"c:\Programas\Sandboxie\start.exe" "RunDLL32.EXE SHELL32.DLL,OpenAs_RunDLL" <curitem>';
Parsed & Resolved:
run
----
"c:\Programas\Sandboxie\start.exe" "RunDLL32.EXE SHELL32.DLL,OpenAs_RunDLL" <curitem>
This one gets close but the use of single quotes '...' as the outer quotes means XY doesn't resolve any variables within the string. If start.exe can handle the passed parameters ("RunDLL32.EXE SHELL32.DLL,OpenAs_RunDLL" <curitem>) then it's going to be passing <curitem> literally to RunDLL/Shell32 instead of resolving it to D:\test.txt.
Code: Select all
run """c:\Programas\Sandboxie\start.exe"" RunDLL32.EXE SHELL32.DLL,OpenAs_RunDLL ""<curitem>""";
Parsed & Resolved:
run
----
"c:\Programas\Sandboxie\start.exe" RunDLL32.EXE SHELL32.DLL,OpenAs_RunDLL "D:\test.txt"
This is even closer but for whatever reason RunDLL32.exe doesn't handle the quotes around D:\test.txt like most other apps, for better or worse.
Code: Select all
run """c:\Programas\Sandboxie\start.exe"" RunDLL32.EXE SHELL32.DLL,OpenAs_RunDLL <curitem>";
Parsed & Resolved:
run
----
"c:\Programas\Sandboxie\start.exe" RunDLL32.EXE SHELL32.DLL,OpenAs_RunDLL D:\test.txt
So why does this work? The outermost quotes tells XY this is the entire parameter, and since they are double quotes XY also parses and expands <curitem> to D:\test.txt. We must surround start.exe with quotes because we're also passing arguments to it, and double quotes are preferred (by Windows) so we need to escape them by doubling them up inside the string. start.exe and rundll32.exe seem to function just fine without their arguments being quoted so we don't bother adding more, but if they needed the arguments quoted we could surround them like we did start.exe.
So some notes to take away from this...
Double quotes ("string") tells XY to resolve any contained variables.
Single quotes ('string') tells XY NOT to resolve any contained variables.
To insert the outer quotes within your string double them up: "contains ""double"" quotes" / 'contains ''single'' quotes'.
It makes sense (and IMO is good practice) to always quote the parameters you provide to XY's scripting commands, as it helps both you and XY understand where each parameter starts and ends.
Run and similar commands typically want the first parameter to be a string containing: "app" arg1 argN
But depending on how app operates you may need to place the arguments in quotes as well: "app" "arg1" "argN".
So this means a run command will generally look like either:
Code: Select all
run """app"" arg1 argN";
run """app"" ""arg1"" ""argN""";
All these quotes can be a bit confusing at times so if you prefer you can use the quote scripting command:
Code: Select all
run quote("app" arg1 argN);
run quote("app" "arg1" "argN");
However remember that many common characters have special meaning in XY scripts when not contained in a string so...
Code: Select all
quote(a.b,c.d); //won't give you "a.b,c.d" but instead results in "ab".
quote(a;); //isn't even valid.
(Side-note: This is why I personally avoid Quote(). It gives a false sense of security and can do more harm than good.)
The best way to test your quoting is to enable stepping and view how XY interprets and parses your command (bottom of stepping window). However, this only helps you understand what XY is doing, and the app you wish to execute may have its own rules for how it handles arguments and needs quotes.
Lastly, don't be afraid to ask for help. Getting the quotes just right can be extremely confusing and frustrating, even when you feel you understand the rules well.
