By Kevin Finnegan
Long time lurker and now forum poster! I'm writing a relatively simple backup script for my firm that automates the copy, compression and organization of Leaver's data on one of our secured NAS systems. I personally found the best method to do this so far was to use 7zG.exe (GUI version of 7Zip which can use command-line too) and it functions quite well!
I would like to retrieve more info on whether any warnings or errors happen in 7Zip during the backup, but I can't quite get my head around the syntax and switches for reading out, it seems any adjustment I make to the RunWait call's string seems to break the backup or give unexpected repercussions! Hopefully its something silly I'm doing as I don't code very often.
Here is the working version:
; Compress the directories one by one in the zip using the listfile.... Local $iPID = RunWait(@ScriptDir & "\bin\7zG.exe a -mx" & $compressionQuality & " -v" & $compressSplitFileSize & " -wc:\temp " _ & $backupToLocation & "\" & $userDirectory & ".7z @bin\listfile.txt -x@bin\excludefile.txt", "", @SW_SHOWDEFAULT, $STDOUT_CHILD) Ultimately I would love to switch entirely to 7za.exe (standalone) so that I can read the progress percentage, current file being uploaded and any warnings or errors could be processed and output to the AutoIT script's GUI I've created rather than jumping in and out of two applications per se.
A fullscreen console with custom commands!
This funny project started as a question in the help section:
I'd like to share this script with everyone that is interested.
Why would I want it?
You like the old style fullscreen console (like in the old day's), You can add custom commands, You can customize the font a lot more compared to cmd.exe, You can share ideas or add tweaks to the script.
Still to do:
Write a simple custom programming language to implement this tool. Writing a little help file / pdf to describe my little programming language. Add little sound effects like a beep if there is a syntax error (optional). Clean up and modify Console.Au3 content. Add an option to have to type a login password (optional). Make an optional installer that also gives scripts for this tool a custom icon and open with command. ...Call Neo?
xxaviarxx: debugging, some ideas. jguinch: debugging, adding a bunch of tweaks and ideas. kylomas: debugging, new ideas.
Edits and updates:
Added usage of tab key in edit control Edit has focus now on startup I'm currently rewriting a simple custom programming language to implement this tool.
UDF download: Console.au3
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.
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?
I am running the tomcat batch file through autoit and need to wait until the below line I get in console output.
But when I am trying to read the console output using the ProcessEx UDF, I am getting only the partial output.
So, can you please suggest how to handle this.
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...
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:
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