Hi William,
I try always to avoid pidof , because (as you said already) in theory there can run another process of a program (in this case rsync)
Very little chance, of course, in case of remasterdog, but I have some sort of rule to always determine the exact pid(s).
Same goes for 'killall', it can be easy solution, but not a good practice to use in scripts IMO.
(but I'm sure there are exceptions).
Btw, I'm always struggling with while loops, I don't know, maybe the progress code can be made more simple or compact.
Edit: Below edits, for information, hopefully someone once might create a solid bash code for a copy progress bar (copy directory to another directory) by using yad, zenity or Xdialog, I didn't succeed yet without using some (ugly?) workarounds.
Edit1:
I note that he is no longer using CPPID at all and instead has an infinite while loop and another while loop inside that which tests for the existence of a $RSYNCPID value to determine whether to break out of the outer while loop...
Toni found out that adding 'wait' after progress code worked but disadvantage is that there could be a long delay after progress bar has closed.
My code, in fact, adds a wait while progress bar is still visible.
Edit2: I've tried "while [ $(pidof rsync) ]; do", btw, but it didn't solve the problem that the progress bar closed earlier than the rsync processes.
The problem was because of not accurate calculating the size of TOTAL (source) compared to COPY (destination) values.
(COPY is more than TOTAL at the end, so progress bar closes when reached at 100%, but in fact it's around 99% that has been copied at that moment, specially on slow computer or writing to slow media, such as a flashdrive)
Edit3: Forgot to mention; the first thing I tried to solve was the accuracy of the TOTAL and COPY values and found, by google search, some examples using find piped to du, but CPU usage became much higher because of that, so not a good option, I think.
So, making a perfect copy progress bar code without some workarounds seems not possible to me.
Fred