0
$\begingroup$

I am trying to automate the submission of many executables with variable parameter values via Mathematica on Windows 10 x64.

Running the executable from Mathematica works great for executables that take no arguments via the following:

Run["myExecutable.exe"]

If - however - you wish to feed in parameter values, the following is the closest I get to the desired behavior (where the "900..." are my arguments to be passed to the EXE):

RunProcess["myExecutable.exe","ExitCode","900 0.01 2 30 30"]

However, on my machine this requires 15% CPU usage by the executable (as expected) & another 15% CPU usage from the Mathematica kernel itself, unlike the Run[~] above. This is because RunProcess[~] returns something to the Mathematica kernel, whereas Run[~] does not; this bug is reported here. This halves the efficiency of scripting and makes it unfeasible!

To avoid this bug in RunProcess[~], I am wondering if there is either:

1) a likely undocumented way to make RunProcess[~] not return anything, thus preventing the kernel from chunking away @ 15% CPU usage waiting on an exit code (or other info),

2) a way to feed in arguments via Run[~] instead?

For (1), I've no idea; according to docs & returned errors, there's no "None" option available for arg2.

For (2), there are guides on how to make Run[~] feed in arguments here from a WRI employee and elsewhere on the Stack Exchange site, e.g. here.

(2) boils down to my not understanding what the Windows Command Prompt needs to see in order to feed in those parameters. This is addressed in part in the first of the above two links, but I cannot for the life of me figure it out. However, I would think RunProcess[~] must know, because it works, it just hogs 2x the necessary CPU usage! But I do not know what it "says" to the command prompt in order to run the executable and feed in the arguments! Another resource regarding this topic is here

Does anyone know how properly feed in arguments to Run[~] on Windows, or StartProcess[~] even given the work-around here sounds as if it works on Linux? (See below.)

While I don't have a minimal working example with a personally compiled exectuable, the behavior can be observed using this (again from here):

RunProcess[{"sleep","10"}]

vs.

Run["sleep 10"]

Unlike for the Linux instantiation I believe users in that referenced question are using, Run["sleep 10"] does not pass the argument appropriately on Windows, (i.e. Run["myExecutable.exe 900 0.01 2 30 30"] does not work on Windows as an equivalent to the resource-hogging yet functional RunProcess["myExecutable.exe",...] above)! :-(

The seemingly Linux-friendly work-around (again here) using StartProcess[{"myExecutable.exe", "900 0.01 2 30 30"}] successfully runs the exectuable, but it waits indefinitely come time to feed in arguments, implying there is an issue feeding in arguments (despite the format being the same as what works with RunProcess[~]. I have tried segregating arguments using StartProcess[{"myExecutable.exe", "900", "0.01", "2", "30", "30"}] to no avail.

Improve this question
$\endgroup$
5
  • $\begingroup$ Did you try the "workaround" (using StartProcess) proposed in the thread concerning the bug with RunProcess ? $\endgroup$
    – SquareOne
    Commented Jan 3, 2018 at 10:52
  • $\begingroup$ Hi @SquareOne, thank you. Yes I tried that. It does run the executable, but the executable hangs when it comes time to feed in the arguments. That is, unless I insert a RunProcess[~] as above, but that then reproduces the above highlighted bug. Hanging when it comes time to feed in arguments with my executable (and seemingly not actually sleeping for 10s with RunProcess[{"sleep", "10"}] is called) seem to boil down to not properly feeding in arguments with Run[~] and StartProcess[~] on Windows, however it works for RunProcess[~] in the same environment, just with 100% overhead. $\endgroup$
    – Ghersic
    Commented Jan 3, 2018 at 23:29
  • $\begingroup$ As the RunProcess way seems clearly buggy for now, you should focus on Run. There are probably examples on this site where Run works successfully with windows for commands with arguments ? Report here if they work for you also. But it's weird that, if I understand well, even the simple Run["sleep 10"] does not work for you with windows OS? Try maybe to follow the strategy described in this post you cited earlier, using cmd.exe command on windows prompt and then from mma with Run. (I can't help, i have OSX). $\endgroup$
    – SquareOne
    Commented Jan 4, 2018 at 11:08
  • $\begingroup$ Thanks, @SquareOne. I haven't a solution on the Mathematica end, but the difference between how Run[~] & RunProcess[~] feed in arguments is such that RunProcess[~] circumvents the expectation that when using Run - with a C++ written EXE feeding in parameters using the console input "cin" command - the parameters must be fed in AFTER the command calling the EXE is entered; parameters can't be entered as in "sleep 10" if the "sleep.exe" was compiled with the input using "cin". However, using RunProcess arguments work; perhaps internally it enters arguments AFTER calling the EXE. $\endgroup$
    – Ghersic
    Commented Jan 9, 2018 at 2:45
  • $\begingroup$ I will leave the question open as others may come across the bug or infer from the question a better resolution than changing the EXE source code; I am still not convinced Run["sleep 10"] behaves properly on Windows. On the off-chance someone is having this issue with a C++ EXE they wrote, if you use the Boost library to use flags to indicate parameters, it will work in a single line such as "sleep -t 10", which may then be used with Run[~]. $\endgroup$
    – Ghersic
    Commented Jan 9, 2018 at 2:48

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.