Search the Community
Showing results for tags 'STDERR'.
Found 5 results
Initial Problem I've written several scripts with the following sequence: Execute a program using Run w/stdout+stderr captured Typically processes all the files in one directory tree to populate a second tree Execute a second program (also with Run) to monitor the products of the first program and Display a progress bar (percentage of output files complete) Also monitor the first program's process and exit when it terminates The script then calls ProcessWaitClose (no timeout) on the first program's process and Checks the first program's results Kills the monitor program if it hasn't already exited on its own. Sometimes, ProcessWaitClose returns 1 with @error = 0 and @extended = 0xCCCCCCCC (actually, 0xFFFFFFFFCCCCCCCC), which seems ambiguous: the documentation says that @error = non-zero and @extended = 0xCC... means an invalid PID (unclear what the return value is), and 1 is returned for non-existent processes (but no mention of @extended). The 1/0/0xCC... result seems to occur when the first program exits very quickly (with or without an error). Since the exit value is not available, the script scans the program's output and tries to determine whether it ran successfully. This has gotten complicated and unreliable. Partial Fix I've now implemented a much simpler approach that works for most cases: Modify the monitor program so that it ignores the other program's process (the monitor always gets killed by the script anyway) Execute the monitor program first using Run, then execute the processing program with RunWait When RunWait returns, the child process exit value is available, so the script can ignore its output (which isn't available anyway) If the monitor program is still running, kill it. Remaining Issue However, there are still a couple of cases where it's necessary to get both the exit value from the processing program and its output. Since RunWait doesn't capture stdout and stderr for the parent script, it's looking like I'll have to call RunWait and redirect the 2 streams to a temp file and then scan it. Also, to do the redirect, I think I'll have to use @ComSpec to execute the processing program, which adds an undesired layer. Does anybody have a better (cleaner) way to handle these cases?
842 downloadsHello Everyone , Are you tired of searching the forum for getting both the exit code & the stdout output? Then your are in the right place! With this UDF you can get the both output & exit code of the command or the console app! Or you can get the exit code of another process without having to use RunWait... Features: 1. Simple & Lightweight (15 KB) 2. Detailed comments & description 3. Flexible functions with many optional parameters A BIG THANKS TO PsaltyDS for the functions! 2 of the (main) functions in the UDF are his work List of functions:
Hello Everyone , Are you tired of searching the forum for getting both the exit code & the stdout output? Then you are in the right place! With this UDF you can get the both output & exit code of the command or the console app! Or you can get the exit code of another process without having to use RunWait... Features: 1. Simple & Lightweight (15 KB) 2. Detailed comments & description 3. Flexible functions with many optional parameters A BIG THANKS TO PsaltyDS for the functions! 2 of the (main) functions in the UDF are his work List of functions: Downloads: Grab the latest (in development) code from GitHub Hope it may help you, TD P.S Icon made by Freepik from www.flaticon.com, Modified by TheDcoder
Someone told me I should post this in the examples section. I wrote this to make it easy for me to call a Windows console application and get its output using a single line of AutoIt code. I hope it's helpful to someone else. #include <Constants.au3> ; Examples: MsgBox(0,"Windows Version",_RunWaitGet(@ComSpec & " /c ver",1,"",@SW_HIDE)) MsgBox(0,"System Info",_RunWaitGet(@SystemDir & "\systeminfo.exe",1)) ; #FUNCTION# ==================================================================================================================== ; Name ..........: _RunWaitGet ; Description ...: Runs the specified process, waits for it to exit, then returns the contents of its StdOut and/or StdErr streams. ; Handy for running command-line tools and getting their output. ; Syntax ........: _RunWaitGet($sProgram, $nOptions, $sWorkingDir, $nShowFlag) ; Parameters ....: $sProgram - The full path of the program (EXE, BAT, COM, or PIF) to run ; $nOptions - Add options together: ; 1 = Capture the StdOut stream. ; 2 = Capture the StdErr stream. ; 4 = Return when the stream(s) close(s), not when the process ends. ; $sWorkingDir - The working directory. Blank ("") uses the current working directory. ; This is not the path to the program. ; $nShowFlag - The "show" flag of the executed program: ; @SW_SHOW = Show window (default) ; @SW_HIDE = Hidden window (or Default keyword) ; @SW_MINIMIZE = Minimized window ; @SW_MAXIMIZE = Maximized window ; Return values .: String value containing the captured contents. ; If there was a problem running the process, @error is set to the @error value returned by Run(). ; Otherwise, @error is 0. ; Author ........: ToasterKing ; Modified ......: ; Remarks .......: ; Related .......: ; Link ..........: ; Example .......: MsgBox(0,"System Info",_RunWaitGet(@SystemDir & "\systeminfo.exe",1)) ; MsgBox(0,"Windows Version",_RunWaitGet(@ComSpec & " /c ver",1,"",@SW_HIDE)) ; =============================================================================================================================== Func _RunWaitGet($sProgram,$nOptions = 0,$sWorkingDir = @SystemDir,$nShowFlag = @SW_SHOW) Local $nRunOptFlags = 0,$sStreamOut = "" ; Initialize variables ; Determine flags for parent/child interaction If BitAND($nOptions,1) Then $nRunOptFlags += $STDOUT_CHILD If BitAND($nOptions,2) Then $nRunOptFlags += $STDERR_CHILD Local $hRunStream = Run($sProgram,$sWorkingDir,$nShowFlag,$nRunOptFlags) ; Run the process If @error Then Return SetError(@error,@extended,0) ; If there was an error code, return it. Otherwise... While 1 ; Loop until the end of the stream, which indicates that the process has closed it (which usually means the process ended) If BitAND($nOptions,1) Then ; If user specified to capture STDOUT stream... $sStreamOut &= StdoutRead($hRunStream) ; Append new stream contents to existing variable while removing those contents from the stream. If @error = 2 And BitAND($nOptions,4) Then ExitLoop ; If stream ended and user specified to return when the stream closes, stop looping. EndIf If BitAND($nOptions,2) Then ; If user specified to capture STDERR stream... $sStreamOut &= StderrRead($hRunStream) ; Append new stream contents to existing variable while removing those contents from the stream. If @error = 2 And BitAND($nOptions,4) Then ExitLoop ; If stream ended and user specified to return when the stream closes, stop looping. EndIf If Not BitAND($nOptions,4) And Not ProcessExists($hRunStream) Then ExitLoop ; If using the default setting and the process ended, stop looping. Sleep(100) ; To avoid overloading the CPU WEnd Return SetError(0,0,$sStreamOut) ; Return the captured contents and @error = 0 EndFunc
I was thinking earlier that perhaps ConsoleWriteError() should be merged with ConsoleWrite() as a parameter. The parameter values could be as such: 0 - <default> Write to STDOUT1 - Write to STDERRWhile this would be a script breaking change it is a logical idea as they both write to console, just different pipes. However, would there be anything that could go horrible wrong with this change that I'm missing?