Return error messages from Command Prompt window?

[gpapp]

If a command is submitted to the Command Prompt Window from Macro Scheduler, is there a way to detect and return error messages?

Here is a typical string being sent to the Command Prompt:

runprog.exe -a -f "C:\My Folder\filename.txt"

Note that this command string runs an EXE inside the command prompt.

Unfortunately I do not have access to runprog.exe and it only wants to run inside a Shell window. The original way this ran inside of Visual Basic was as follows:

set myShell = myShell.exec ("runprog.exe -a -f """C:\My Folder\filename.txt""")
errmsg = LCase(myShell.StdOut.ReadAll)

Note the extra double quotes to force the Shell to pass through the string properly becuse of the space in My Folder's name.
I am asking if there is any way to trap errmsg using Macro Scheduler.

[JRL]

What happens if you run like this:

Code: Select all

Let>rp_wait=1
Run>runprog.exe -a -f "C:\My Folder\filename.txt" > %temp_dir%error capture.txt
readfile>%temp_dir%error capture.txt,data
mdl>data

[gpapp]

it looks like using > to redirect standard out might work.
I'll test it out ASAP and let you know.
Thanks

[gpapp]

Thanks much for the suggestion.

I have verified that the > method works.
It turns out I need to capture Standard Out and also Standard Error, so the Scheduler code is modified as follows:

setfocus>C:\WINDOWS\system32\cmd.exe*

sendtext>%mycommand% >> C:\Temp\Statusmsg.txt 2>&1

In this example, The Command window is named as shown.

"mycommand" can be a .BAT file or a .EXE that is set up to run in the Command Window

The >> means that Statusmsg.txt will be appended with new messages.
The " 2>&1 " appended to the end of the command means it will trap both Standard Out and Standard Error messages.

A good reference is http://www.robvanderwoude.com/redirection.php

[Dick99999]

You might want to consider handling the following situations:
- lock the keyboard before the focus, then send text and then unlock it again
- a way to reliably determine whether the message output file (>>) is really 'ready'. If not you will get an error message about another process accessing this file.

I found the last item complicated to solve, I chose 2 actions that solved it .... for now....
1. always execute a second dummy command that generates its own >> output. when that exists the first one is at least executed
2. then test the output of the first (real) command by reading a line. If that line is ##ERR## the file is still locked. I did this in a loop that times out.

[adroege]

I think this might be your best solution:


http://www.mjtnet.com/forum/viewtopic.p ... highlight=


Using this technique, no temporary files are written.

[Marcus Tettmar]

Thanks much for the suggestion.

I have verified that the > method works.
It turns out I need to capture Standard Out and also Standard Error, so the Scheduler code is modified as follows:

setfocus>C:\WINDOWS\system32\cmd.exe*

sendtext>%mycommand% >> C:\Temp\Statusmsg.txt 2>&1

Is there any reason why you must send characters to the command window? Why can't you do this:

Let>RP_WAIT=1
Run>cmd.exe /c %mycommand% >> C:\Temp\Statusmsg.txt 2>&1

And as you have suggested pipe output to a text file which you can read in and parse/evaluate with ReadFile.