Just annotations of little "how to's", so I know I can find how to do something I've already done when I need to do it again, in case I don't remember anymore, which is not unlikely. Hopefully they can be useful to others, but I can't guarantee that it will work, or that it won't even make things worse.
"Wait until a process ends, a download ends, or a file conversion ends, then do X"
Posted 08-30-2011 at 03:06 PM by the dsc
Updated 08-30-2011 at 09:41 PM by the dsc (a small improvement)
Updated 08-30-2011 at 09:41 PM by the dsc (a small improvement)
Tags bash, helper scripts, tools, wait
Sometimes you want the computer to shut down after you've finished downloading something or converting some large file into some other format, but you want to go out or go to sleep instead of waiting and checking for it yourself.
For these situations I've come up with two tiny scripts. The first one waits until a file hasn't changed its size on three consecutive intervals of twenty seconds:
You'd use it like:
waitfile <file you're downloading or the output of some conversion> && <do whatever you want, like sudo shutdown -h now>
(without the less/more-than brackets)
The point of the whole checking on the existence of a "$file.part" is to have it compatible with firefox' downloads without having to bother remembering to explicitly point it to the temporary file that firefox uses. If such file exists, it assumes it's dealing with a firefox' download, and thus checks the .part file, not the file with the actual name, which would have a "zero" size for a good while. But it's not specific to firefox' downloads at all.
The next one waits until a process no longer exists:
The "syntax" is the same:
waitfor <whatever program/process that is expected to exit by itself at some point> && <whatever you intend to do after it finishes without having to personally wait for it>
I guess that this one can be a bit tricky sometimes depending on what you have running. Perhaps there will be more than one result for the same "grep" on "ps -A", so it could theoretically wind up waiting for more than one process, not only the one you have in mind. And this other process could "never" finish for whatever reason. An example that comes to my mind is a paused instance of mplayer (which wouldn't ever exit) or gmplayer (which does not exit as it reaches the end of the file), running concurrently with an instance of mplayer (which exits when it reaches the end of whatever it was playing, when it's not on slave mode).
For these situations I've come up with two tiny scripts. The first one waits until a file hasn't changed its size on three consecutive intervals of twenty seconds:
Code:
a=0 ; file="$1" ; if [ -f "$file.part" ] ; then file="$file.part" ; fi ; until ( (a==3)) ; do if [ ! -f "$file" ] ; then exit 0 ; fi ; size1=$(stat -c%s "$file") ; echo $size1 ; sleep 20s ; size2=$(stat -c%s "$file") ; echo $size2 ; if [ $si ze1 == $size2 ] ; then a=$((a+1)) ; echo $a ; else a=0 ; fi ; done exit 0
waitfile <file you're downloading or the output of some conversion> && <do whatever you want, like sudo shutdown -h now>
(without the less/more-than brackets)
The point of the whole checking on the existence of a "$file.part" is to have it compatible with firefox' downloads without having to bother remembering to explicitly point it to the temporary file that firefox uses. If such file exists, it assumes it's dealing with a firefox' download, and thus checks the .part file, not the file with the actual name, which would have a "zero" size for a good while. But it's not specific to firefox' downloads at all.
The next one waits until a process no longer exists:
Code:
until [[ ! `ps -A | grep $1` ]] ; do echo "$1 still running" ; sleep 5 ; done
waitfor <whatever program/process that is expected to exit by itself at some point> && <whatever you intend to do after it finishes without having to personally wait for it>
I guess that this one can be a bit tricky sometimes depending on what you have running. Perhaps there will be more than one result for the same "grep" on "ps -A", so it could theoretically wind up waiting for more than one process, not only the one you have in mind. And this other process could "never" finish for whatever reason. An example that comes to my mind is a paused instance of mplayer (which wouldn't ever exit) or gmplayer (which does not exit as it reaches the end of the file), running concurrently with an instance of mplayer (which exits when it reaches the end of whatever it was playing, when it's not on slave mode).
Total Comments 0
