How to wait for a set sub-processes to finish - wait

I have a master process A.sh and set of sub-processes a1.sh, a2.sh and a3.sh These are executed in this example
./A.sh & // master
./a1.sh &
./a2.sh &
./a3.sh
I need to wait till these sub-processes finish before I can start another set of sub-processes say b1.sh, b2.sh, b3.sh in similar manner
./A.sh & // master
./a1.sh &
./a2.sh &
./a3.sh &
// sleep for a1, a2, a3 to finish, then start
./b1.sh &
./b2.sh &
./b3.sh &
"wait" commands waits for entire background processes to finish, how do I do it for the set of sub-processes, Do I get wait on basis of every pid of sub-process.

Related

Making AutoIT wait until Audacity completes command

I have a script that I'd like to use to automate processes in Audacity. I have it set up so that all the functions I want to do in Audacity are keyboard shortcuts (since I don't think Audacity uses standard window menus like is required for WinMenuSelectItem()) In other words, my whole code consists of multiple instances of the Send() command. The problem is, AutoIT executes the code too fast. I've tried using WinWait(), but the processes take variable amounts of time. I've also tried ShellExecuteWait() and RunWait()Is there a way to get it to wait until the program isn't doing something, and then execute my send commands? Here's some of my code
Run("C:\Program Files (x86)\Audacity\audacity.exe")
; wait until it's active
WinWaitActive("Audacity")
; get the dialogue box to go away
Send("{ENTER}")
RunWait("Audacity")
; open files
Send("^o")
RunWait("Audacity")
; open the certain file & press enter
Send("test.wav")
RunWait("Audacity")
Send("{ENTER}")
RunWait("Audacity")
; select left boundary of silence period
Send("[")
RunWait("Audacity")
Send("000000100{ENTER}")
RunWait("Audacity")
; select right boundary of silence period
Send("]")
RunWait("Audacity")
Send("200000000{ENTER}")
RunWait("Audacity")
; Use for debugging issues. Systray icon show current line.
Opt('TrayIconDebug', 1)
; Delay default: 250s
Opt('WinWaitDelay', 400)
; Delay default: 5s
Opt('SendKeyDelay', 100)
; Path of the wav file.
$sInFile = #WorkingDir & '\test.wav'
; Optional permanent change of splash screen setting.
_SplashScreen(True)
; Run Audacity and argument of the wav file.
$iPid = Run('"C:\Program Files (x86)\Audacity\audacity.exe" "' & $sInFile & '"')
; Check if Run Audacity failed.
If #error Then
MsgBox(0x40030, #ScriptName, 'Failed to run Audacity')
Exit 1
EndIf
; Wait for main window to get handle. Title is the filename with no extension.
$hMainWindow = WinWait('[TITLE:test; CLASS:wxWindowNR]', '', 10)
; Check allowed timeout of window.
If Not $hMainWindow Then
MsgBox(0x40030, #ScriptName, 'Audacity window not detected.')
Exit 1
EndIf
; If splash screen setting not 0 then handle the window.
If _SplashScreen() Then
AdlibRegister('_WelcomeWindow')
WinWait('Welcome to Audacity', '', 3)
AdlibUnRegister('_WelcomeWindow')
EndIf
; Send '[' to main window to trigger Left Boundary window.
ControlSend($hMainWindow, '', '', '[')
; Get handle of Left Boundary window.
$hMsgWindow = WinWait('Set Left Selection Boundary', '', 5)
; Check allowed timeout of window.
If Not $hMsgWindow Then
MsgBox(0x40030, #ScriptName, 'Selection Boundary window not detected.')
Exit 1
EndIf
; Activate window, set time and click OK.
If WinActivate($hMsgWindow) Then
ControlSend($hMsgWindow, '', 'wxWindowNR1', '{LEFT 3}1'); 1000
ControlClick($hMsgWindow, '', 'Button2'); OK
EndIf
; Send ']' to main window to trigger Right Boundary window.
ControlSend($hMainWindow, '', '', ']')
; Get handle of Right Boundary window.
$hMsgWindow = WinWait('Set Right Selection Boundary', '', 5)
; Check allowed timeout of window.
If Not $hMsgWindow Then
MsgBox(0x40030, #ScriptName, 'Selection Boundary window not detected.')
Exit 1
EndIf
; Activate window, set time and click OK.
If WinActivate($hMsgWindow) Then
; Audacity shows 1000 and focus is on the 1st non zero digit which is 1.
ControlSend($hMsgWindow, '', 'wxWindowNR1', '2'); 2000
ControlClick($hMsgWindow, '', 'Button2'); OK
EndIf
; More code to do.
Sleep(1000)
MsgBox(0x40040, #ScriptName, 'End of automation.' & #CRLF & #CRLF & _
'You can close Audacity to finish.')
; Wait for Audacity process to close.
ProcessWaitClose($iPid)
Exit
Func _WelcomeWindow()
; Used by AdlibRegister to handle the Welcome window.
; Welcome window hides if closed so need to check if exist and is visible (2).
If WinExists('Welcome to Audacity') Then
If BitAND(WinGetState('Welcome to Audacity'), 2) Then
WinClose('Welcome to Audacity')
Else
AdlibUnRegister('_WelcomeWindow')
EndIf
EndIf
EndFunc
Func _SplashScreen($bDisable = False)
; Write to audacity.cfg to disable splash screen.
Local $sIniFile = #AppDataDir & '\Audacity\audacity.cfg'
If IniRead($sIniFile, 'GUI', 'ShowSplashScreen', '1') = '1' Then
If $bDisable Then
; Return 1 if ini file change is success.
If IniWrite($sIniFile, 'GUI', 'ShowSplashScreen', '0') Then
Return 1
EndIf
Else
; Return 1 if check for splash screen is enabled.
Return 1
EndIf
EndIf
EndFunc
Opt() is used to slow down the wait of windows and the sends.
Also added Opt('TrayIconDebug', 1) for debugging though if
the script is considered good then you can remove that Opt().
ControlSend() is used instead of Send() as ControlSend()
targets windows and controls based of title, text, etc.
The Opt() delays are not required though was added to
demonstrate the usage, though perhaps Audacity may struggle
to keep with the speed that AutoIt can automate.
If possible, suggest use of Control*() functions for automation.
Storing window handles in a variable can help save retyping titles
in the code. WinWait() returns a window handle which is ideal and
if the timeout parameter is used, then 0 indicates the window not
found so automation can be aborted.
The Classname of the main window is not enough on its own as
Audacity creates many invisible windows with the same Classname.
So, the title may need to be used as well. The title could be
used alone though titled by filename may not be unique at times.
See Window Titles and Text Advanced for usage.
WinActivate() is used on the Boundary windows although it
may not be needed as control*() usually do not need active
windows. Standard Msgboxes in comparison may require to be
active to accept messages sent to them.
ShellExecuteWait() and RunWait() are no good for automation
as they block the script from continuing until the executed
process has finished.
So use ShellExecute() or Run() instead.
The repetitive use of RunWait("Audacity") seems like
desperation to correct the behavior perhaps, though flawed.
Waiting for windows to appear is how to control flow and then
functions such as ControlCommand() can detect state of controls.
ControlClick() is used on the buttons.
CtrlID of Classname Button2 is used though if the script
is always for English users then you can use the text which
would be OK for the OK button.
The ProcessWaitClose($iPid) is optional.
It is sometimes useful to wait for the program
being automated to exit before the script exits.
You comment "get the dialogue box to go away" in you code
after starting Audacity. You can change the setting on the
dialogue box or Preferences -> Interface options. Advice
disabling as it is a future problem to keep handling.
I added some code to disable the setting in the
audacity.cfg file. If not preferred to disable with
_SplashScreen(True) or done manually then
the AdLibRegister('_WelcomeWindow') call will handle
closing the window. Note that the Welcome window does
not close but rather hides.
_SplashScreen(True) changes splash setting to 0 to disable the splash.
_SplashScreen(False) or _SplashScreen() does no change of settings.
The call returns 1 if splash is enabled else 0.

sometimes serial write operation blocks after initializing

I have my embedded linux box with 2 serial ports application, which tests all serial ports with wrap cable (only Rx connected to Tx, no other pins).
The second (non-console) port works fine.
The first (console) port sometimes works, but sometimes does inexplainable things.
To test the first channel I kill running 'getty' before opening it. The respawn is also forbidden.
Then I do the following:
system("killall getty");
Sleep(1000);
if ((fd = open(Name, O_RDWR | O_NOCTTY | O_NONBLOCK)) <= 0)
MsgFatal("Serial '%s' open error %d.", Name, errno);
BRN = B115200;
tcgetattr(fd, &Opts);
cfsetispeed(&Opts, BRN);
cfsetospeed(&Opts, BRN);
cfmakeraw(&Opts);
Opts.c_cflag |= PARENB;
Opts.c_cflag |= PARODD;
Opts.c_cflag &= ~CSTOPB;
Opts.c_cflag &= ~CRTSCTS; /* no HW flow control */
Opts.c_cflag |= CLOCAL | CREAD;
tcsetattr(fd,TCSANOW,&Opts));
After this, SOMETIMES (I mean on some run of the application) the next write operation blocks!
Any advice will be highly appreciated.
First off, the death of a getty process should immediately be reaped by its parent, either init or an aspect of BusyBox, and relaunched. How long it takes can vary, but it is usually pretty quick. But that shouldn't affect writing to the port.
How do you know the write is blocking? Please show that code.

Will using "yes" command in unix waste lot of cpu cycles?

Will using "yes" command waste lot of cpu cycles ?
I have a long running script (script code not in my control) which accepts something as input just once. Then the script runs for long time .
To automate I use "yes" command to feed the input
yes hello | myscript
Will yes command steal/waste lot of cpu cycles ?. As per the docs i read it keeps printing the string argument to piped program
I gave top command , i didnt see "yes" there in top
yes will print the string "hello" when it has the chance - this means that the receiving end (your script) must be waiting for I/O (i.e., expecting input). So: no, yes does not take any CPU when the receiving end does not wait for input, the process is blocked.
See the run state of the process yes in a ps auxf for confirmation.

what is the result of Z+ in ps command?

i made a zombie process with this code :
pid_t child;
cout<<getpid();
child=fork();
if (child>0)
sleep(60);
else
exit(0);
and i'm using this command :
ps -e -o pid,ppid,stat,command
it's okey , but i expect see Z in front of my process(stat) but it's Z+ , what thats mean ?
From the man page for ps, more specifically the process state codes:
Z defunct ("zombie") process, terminated but not reaped by its parent.
+ is in the foreground process group.
When the shell executes your code, it changes your program to a separate foreground process group. Every child of your code is in the same foreground process group as the original program, so even once the parent exits, the child is still in the foreground process group which is why you see the +.

Darwin: how to kill parent process without killing child?

On OS X 10.4/5/6:
I have a parent process which spawns a child. I want to kill the parent without killing the child. Is it possible? I can modify source on either app.
As NSD asked, it really depends on how it is spawned. If you are using a shell script, for example, you can use the nohup command to run the child through.
If you are using fork/exec, then it is a little more complicated, but no too much so.
From http://code.activestate.com/recipes/66012/
import sys, os
def main():
""" A demo daemon main routine, write a datestamp to
/tmp/daemon-log every 10 seconds.
"""
import time
f = open("/tmp/daemon-log", "w")
while 1:
f.write('%s\n' % time.ctime(time.time()))
f.flush()
time.sleep(10)
if __name__ == "__main__":
# do the UNIX double-fork magic, see Stevens' "Advanced
# Programming in the UNIX Environment" for details (ISBN 0201563177)
try:
pid = os.fork()
if pid > 0:
# exit first parent
sys.exit(0)
except OSError, e:
print >>sys.stderr, "fork #1 failed: %d (%s)" % (e.errno, e.strerror)
sys.exit(1)
# decouple from parent environment
os.chdir("/")
os.setsid()
os.umask(0)
# do second fork
try:
pid = os.fork()
if pid > 0:
# exit from second parent, print eventual PID before
print "Daemon PID %d" % pid
sys.exit(0)
except OSError, e:
print >>sys.stderr, "fork #2 failed: %d (%s)" % (e.errno, e.strerror)
sys.exit(1)
# start the daemon main loop
main()
This is one of the best books ever written. It covers these topics in great and extensive detail.
Advanced Programming in the UNIX Environment, Second Edition (Addison-Wesley Professional Computing Series) (Paperback)
ISBN-10: 0321525949
ISBN-13: 978-0321525949
5 star amazon reviews (I'd give it 6).
If the parent is a shell, and you want to launch a long running process then logout, consider nohup (1) or disown.
If you control the coding of the child, you can trap SIGHUP and handling it in some non-default way (like ignoring it outright). Read the signal (3) and sigaction (2) man pages for help with this. Either way there are several existing questions on StackOverflow with good help.

Resources