sc RUN refuses 64 bit exe

[SkyFrontier]

A simple
run "path to 64.exe";
is producing a "system cannot find the specified file", which proves wrong as "path to 64.exe" on AB finds it normally.
Elevated instance of XY.
Any hints?

[admin]

What is the path?

[SkyFrontier]

D:\soft\TypingAssistant_USB_7_0\Typing Assistant64.exe

[admin]

Show your code...

[bdeshi]

Code: Select all

...Typing Assistant64.exe
         ^

there's a space in my boots the path. Enclose in quotes.

Code: Select all

run '"D:\soft\TypingAssistant_USB_7_0\Typing Assistant64.exe"';

[admin]

Next version will show an improved error message that will immediately point to such quoting mistakes...

[SkyFrontier]

Do I really need to put it under 'single"double"' quotes? Never had this problem, before... (And yes, now I see it's not a x64.exe related problem... And since I never needed to run .exes from paths having spaces, until today, I was unaware of such requirement - thinking double quotes were enough to deal with this)

[PeterH]

Do I really need to put it under 'single"double"' quotes?

The 1st operand of the run command is "what to run" - this includes the program *and* it's operands. I.e. "D:\soft\TypingAssistant_USB_7_0\Typing Assistant64.exe" /once
In this example you see that program and operand are separated by blank.
In your case the blank wrongly separates a command (up to the blank) from an operand (behind the blank) - which is obviously wrong. So you have to specify the program in double quotes. (This is Windows syntax!)
All this is a string - and to specify a string in XY you have to quote it.

Imagine you would want to start your program with the operand /once! You would specify:
run '"D:\soft\TypingAssistant_USB_7_0\Typing Assistant64.exe" /once';
Here you see that outer (here: single) and inner (here: double) quotes are not on the same level.

As outer quotes you also could use double quotes - but then you'd have to double the inner double quotes - the result is identical:
run """D:\soft\TypingAssistant_USB_7_0\Typing Assistant64.exe"" /once";

[Stef123]

Glad to see I am not the only who trips up on this.
Important side note that only registered with me after re-reading SC help several times over again: You cannot use single quotes if you pass parameters that need to be resolved, such as

Code: Select all

run """D:\..blahblah\Typing Assistant64.exe"" /once ""<curitem>\""";
openwith ("""path_to_ArchiveHandler"" x -- <items> ""<curpath>""", m) ;

And these are easy (!) examples. When running an app.exe by passing it (and it's parameters) to console.exe things get nested even further. I use many such calls because XY has become my central dashboard and launchpad. And yet I still find it impossible to construct my terms inside SC. Without the color-highlighting of external editors I'd be lost. But that means pasting back and forth between XY and the external editor to step-run and debug.

[SkyFrontier]

Hi, Peter. Thanks for the explanation.
What's new to me here is: if I don't have any explicit parameter, I thought the outer single quote wasn't necessary at all. Depending on what Don will do about, I'll have a good bunch of run-related scripts to revise anytime soon. :sigh:

[Stef123]

What's new to me here is: if I don't have any explicit parameter, I thought the outer single quote wasn't necessary at all.

If I am to believe my own notes/ help compilation, the SC engine strips off outer double quotes. So your call would actually pass "Assistant64.exe" as a parameter because it is preceded by a space.

[admin]

Sigh. Non-programmers...

Man, this is all totally normal, simple, and non-confusing. If you find your lines hard to read break them up into variables:

Code: Select all

$app_quoted = quote("D:\soft\TypingAssistant_USB_7_0\Typing Assistant64.exe");
  run "$app_quoted /once";

Etc.

[Stef123]

Sigh. Programmers...
Meaning to make things easier by introducing yet another complication - variables. Well, glad I have read far enough in SC help to not get thrown off by it

[bdeshi]

Here's another method without using variables:

Code: Select all

  run <<<#CMD
"D:\soft\TypingAssistant_USB_7_0\Typing Assistant64.exe"#CMD ;

[PeterH]

Programmers - yes, but...

If you want to specify some "text" to be used in XY, be it for a variable, or for some operand, this is a string.
To define where the string stops and starts you have to surround it by quotes.
Numbers *can* be just seen as numbers and specified unquoted, or can be quoted. The result is the same.

Now compare:

Code: Select all

 $var = 5;     // might also be "5" or '5'
 echo 3 + $var;
 echo "3 + $var";
 echo '3 + $var';

As the results of the lines are different, *you* have to tell XY by use of quotes *what* you want. So (exact) quoting makes sense.
And it can't be helped: you must use the rules of XY to be able to tell it what you want. Else you won't achieve what you want.

Though it's true: it's getting a bit harder if you need quotes *inside* of a string.