(Untitled)

[tgrey]

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

Comments

[ghettohaxor]

have you tried to return the variable from the function? if you hold it resident durring the background call i think that might do the trick.

[natowelch]

doh. function returns have to be integers, not arrays.

[ghettohaxor]

yes but if you catch output from the function you can parse it. and apply it to the current array

[natowelch]

yeah, that's where I went to. unfortunately, the parsing & assignment has to be done in the foreground, which would block that proc, defeating the purpose.

rough problem...

[natowelch]

Here's my speculation post.

* What about using the return value of the function instead of getting it to tweak a variable in different scopes?

* since backgrounding a process essentially fork()s it, the fork has it's own instance of all the environment (aka bash) variables that it takes with it, that are destroyed when the backgrounded process returns. This sounds pretty normal to me.

There's the export command which is designed for this kind of thing. I use it quite a bit.

I will try a few things, and get back to you with my results.

ooooh, fun! ;p

[tgrey]

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

[romulusnr]

There's a "wait" command in bash that should avoid the /proc fishing.

[tgrey]

interesting... this may help.

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 :)

[natowelch]

I don't think there's a way you can background it and have it retain a reference to another process's variable. I tried using the function's output to assign the variable in the fg proc, but that just blocked the fg proc until it returned.

mrg

[jojotdfb]

roto's right, it's spawning a new copy of the enviroment. Proof is working on it's own copy of the array in and then it's disposeing of all the changes when that proccess ends. If you can do some sort of mutex to share the array between processes, that would do it. You would lock the array in the proof function to make sure that the fg proc couldn't access the array till you where done. I know unix can do that but to be honest, i wouldn't know how to do that in bash (or if it's even possable, google's comeing up with nothing). It's pretty easy in python and other languages that supports threading and multiprocessing.

[tgrey]

Yeah, I realized Roto was right. I don't know of a way to lock mutex style in bash, but even so, it wouldn't help. The whole goal is to acheive threading of sorts. I want multiple proof functions running, the array is to track their status.

Most of what I want to do is so simple, that it'd be a shame to break out Python or C. Majority of the program would be calling bash from system calls anyway.

I had a few ideas to play with today once I've gotten chores and stuff done. Perhaps I'll get lucky. :)

[romulusnr]

export the array before you call the function in the background.

[tgrey]

Nope =\

#!/bin/bash
declare -a TEST

function proof
{
echo 0: ${TEST[0]}
echo 1: ${TEST[1]}
TEST[1]=2
echo 0: ${TEST[0]}
echo 1: ${TEST[1]}
}

TEST[0]=0
TEST[1]=1

export TEST

proof
#proof &
sleep 1

echo 0: ${TEST[0]}
echo 1: ${TEST[1]}

Output:
0: 0
1: 1
0: 0
1: 2
0: 0
1: 1

[tgrey]

Except when I tested this, I really did have the right bg proc uncommented, not as pasted. I pasted the same buffer and added the export.

[romulusnr]

try exporting within the function so that the bg call explicitly exports?

i dunno.

what's your program called?