View Single Post
Old 04-25-2012, 08:08 AM   #33
knc1
Going Viral
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
Quote:
Originally Posted by geekmaster View Post
I did "waitforkey >/tmp/key &" which continues immediately, leaving waitforkey running in the background until a key is pressed, when it outputs the keypress value and quits. While waiting for a key, you can periodically check for a keypress in the main script with "key=$(cat /tmp/key)". You just need to get creative and try stuff...
Important Disclaimer for the following:
What the copy of busybox does that you might be using may vary from the following, you just have to try it to find out.

Every time you start a background job, that command __should__ return a "job id" number.

Then you can do other things, and when ready to proceed with the result of the background job, do a "wait <job id>".

Which will wait for the background job without the cpu overhead of a busy loop wait for the contents of /tmp/key to change. Where changes to /tmp/key is the expected result of the background job in this example case.
knc1 is offline   Reply With Quote