使用变量“值”在KornShell中定义变量“名称”

Question

My program involves a number of JAVA threads calling a KornShell (ksh) script file with different parameters. This script file in turn calls some SQL commands which return some status. I store this status in a variable as a part of the script and check the value returned from SQL and take appropriate actions. The problem is that all scripts are being executed in the same session and thereby the variable name gets shared across all threads. Since these threads are working asynchronously, I want this link to be broken. The easiest solution that I could come up with was to have a different variable for each thread (use some input parameter to the script as an identifier) but this would mean that the name of that variable needs to be dynamic. That is, I should be able to use the value of a variable in the name of another variable. Is this even possible? If it is then how do I do it ?

Java Thread - | Same session | | | Java Thread - - | Same Script | | | Java Thread - - - | Same var name | | |
Java Thread - - | (This same var | | name can cause | Java Thread - | Inconsistencies)|

If not, then can anyone suggest an alternative approach? An important aspect of this is the far that the JAVA part is a server program and will be running for extended durations so I will need to 'unset' these variables manually. (Something I can't do if i am using an array to store all of these)

Answer 1

... I store this status in a variable as a part of the (ksh) script and check the value returned from SQL and take appropriate actions. The problem is that all scripts are being executed in the same session and thereby the variable name gets shared across all threads.

So to summarize:

• each thread uses System.exec(...) or equivalent to run a ksh script

• the ksh script uses a variable to store the status from running an SQL query.

In this scenario, the ksh variable will NOT be shared between the different instances of the running script. Each ksh instance has its own variable set.

There must be another explanation for what is going on here.

---

You say that if [ $var_$val -eq 0 ]; then ... if [ $var_$val -eq 0 ]; then ... gives the wrong answer. I'm not surprised. $var_$val cannot possibly expand to a number, so the test to see if it is zero will always fail.