Ok... so I've found this bizarre behavior in bash. I need a way around it. Here's proof that it does not work as expected, and I'm sure there's a "valid" reason it does this. I need a way around it tho
( Read more... )
Ah. You gave the reason. That is correct, somewhere in my mind I knew that, I just couldn't recall why it was doing this at the moment.
Export from the function didn't seem to affect the global variable as well.
As for return value, maybe I'm mistaken, but I don't think you can assign this to a variable from a background function... but this doesn't sound right to me. I'll investigate the possibility tomorrow.
Yeah. parsing output is an option, and for the actual use I want, I *could* make it work, but I think it's a dirty hack.
Another dirty hack I thought of was using tempfiles... I don't like this option either.
The problem is, I'm using the array to store states of multiple bg procs to make psuedo-threaded programs. I use another array to track the PID's so threads can be cleaned up as necesarry. I need to track the status and see when all of these bg procs are done, so I know I can exit, and display the results.
Short of constantly monitoring the pid to see if it's running...
Wait. I just had an idea. Monitoring for while [ -e /proc/${PIDS[$COUNT]} ]; I think it just might work... I'll have to play with it more tomorrow tho, I'm not touching it anymore tonight.
i'll have to test it's compatability with bash v2 tho. in bash v3 i was watching for ! $(jobs -p) which worked fine... but it seems in v2 a script (non-interactive) doesn't keep track of jobs.
altho, i've since progressed where "wait" might not be a use to me. i'm also throttling only up to a certain number of threads, so i need to now how many are running, and reporting this number to the user.
Export from the function didn't seem to affect the global variable as well.
As for return value, maybe I'm mistaken, but I don't think you can assign this to a variable from a background function... but this doesn't sound right to me. I'll investigate the possibility tomorrow.
Yeah. parsing output is an option, and for the actual use I want, I *could* make it work, but I think it's a dirty hack.
Another dirty hack I thought of was using tempfiles... I don't like this option either.
The problem is, I'm using the array to store states of multiple bg procs to make psuedo-threaded programs. I use another array to track the PID's so threads can be cleaned up as necesarry. I need to track the status and see when all of these bg procs are done, so I know I can exit, and display the results.
Short of constantly monitoring the pid to see if it's running...
Wait. I just had an idea. Monitoring for while [ -e /proc/${PIDS[$COUNT]} ];
I think it just might work... I'll have to play with it more tomorrow tho, I'm not touching it anymore tonight.
What fun. :)
Reply
Reply
i'll have to test it's compatability with bash v2 tho. in bash v3 i was watching for ! $(jobs -p) which worked fine... but it seems in v2 a script (non-interactive) doesn't keep track of jobs.
thanks :)
Reply
$ expr me + bash
insane
Reply
Leave a comment