[added 15.0.23] Run command, capture STDOUT

[Marcus Tettmar]

Can someone confirm that this is working with RP_ADMIN=1?

It cannot work with RP_ADMIN=1 as it has to use a completely different mechanism. (as in, while you can set RP_ADMIN to 1 it will have no effect when using RP_CAPTURESTDOUT). There are likely lots of other caveats we have yet to discover and I suspect I will regret adding this command in about, oh, 20 minutes.

[Marcus Tettmar]

In any case, if you're not admin, and you start something as admin, then you won't have permission to interact with or access that process, so you won't be able to read its STDOUT. Makes no sense. Hence you can't use RP_ADMIN here.

[Grovkillen]

Understood, and no need to regret it. If it's documented it's all good

[Grovkillen]

This works for me:
(Note the use of "Between>" rather than "RegEx>")
Looks like your file is on a shared drive, be sure your admin user has access to the share.

Code: Select all

Let>PATH_TO_FILE=L:\A\Run MyTime.exe

Let>RP_WINDOWMODE=0
Let>RP_CAPTURESTDOUT=1
Let>RP_Admin=1

Let>CMD_TO_RUN=cmd /c certutil -hashfile "%PATH_TO_FILE%" MD5
RunProgram>CMD_TO_RUN
Between>RP_STDOUT,:%crlf%,%crlf%Cert,HASH_OF_FILE,Match_Num
MDL>HASH_OF_FILE_1

My code did work I just added it as a information for others that use the CAPTURESTDOUT. And sometimes you need to terminate the cmd.exe by using the /c switch. I love this feature and are testing it like a mad man to see how it behaves

[Grovkillen]

Maybe just add this to the help:

RP_CAPTURESTDOUT=1 will allow for a capture of the output from a cmd command but beware that you cannot use this together with RP_ADMIN=1 (if set to 1 it will be ignored when RP_CAPTURESTDOUT=1). Also be aware that some commands will output in sessions meaning that not everything might be capture by the RP_CAPTURESTDOUT=1, in that case you should use either a pipe to clipboard or direct the output to an external file. In some cases it will be of help to use the "cmd /c" switch to force the command to terminate and reveal an output. It's a test by case type of deal.

[Grovkillen]

Is this RP_STDOUT variable fetched from a temp file in local data? If so, it needs to be unique (name) because if multiple applications use the capture at the same time the exact same issue as with using clipboard will arise.

[Grovkillen]

Marcus, is my observation true? Can this be a problem?

[Marcus Tettmar]

Nothing is shared. There shouldn't be a clash.

[Grovkillen]

Ok, thanks for the information. Then my findings must be caused by something else but at least I can rule this thesis out of the equation

[Grovkillen]

Nothing is shared. There shouldn't be a clash.

Today the clash happened. A compile script crashed and was started up again. The crash happened during the run command and thus the "output.tmp" file was created in the ...AppData\Local\Temp folder. When the newly started script tried to do a RP_STDOUT read, the output file was locked, resulting in a new crash.

My suggestion is to not have this output.tmp file hardcoded but based on a GUID instead. This way there would be astronomical unlikely to have a clash.

[Dorian (MJT support)]

Have passed this on to dev.

[Grovkillen]

I just wonder if this is planned to be implemented or if I should not expect it to be addressed?

[Marcus Tettmar]

I thought we had already done this and have just checked the source and see that, yes, indeed, the stdout file uses a UID. Perhaps we missed something off the release notes. The latest version is 15.0.24 so maybe it went in there. Can you please make sure you are running 15.0.24 and check again?

[Grovkillen]

I just updated and will wait and see. Sounds like it's fixed then

The update notes could be a tad more informative in this particular case, the "minor fixes" didn't sound too important for me to test

[Grovkillen]

I've been running the latest version for some days now and no crash yet. Thanks for the help.