How to access new variables created with .bset?
Hi folks,
I'm trying to use .bset in steps that get broadcast and threaded. Below environment is all windows. I am using the $ notation because that's what I'm used to. I don't know if that is part of my issue. Therefore I can't use 1 common variable name. Otherwise whatever step that finished last would get the winning value in the variable. I'm trying to do something like this. .bset "${BF_SERVER}_VAR= `(some command)`" This runs and creates a For example, in a broadcast and threaded situation, I might end up with variables like: Server1_VAR Server2_VAR Server3_VAR BF creates these correctly and says they are new variables. However, I can't seem to figure out how to reference them in For example none of the following actually work. ${BF_SERVER_VAR} <results> ${BF_SERVER}_VAR <results in Server1_VAR but not the value it holds) ${${BF_SERVER__VAR} results in ${Server1_VAR} etc it's as if BF does a substitution once but doesn't go back and re-substitute. Any idea? Andy |
7 answers
|
Here are some examples:
STEP .bset env "${BF_SERVER}_ISDIRTHERE = $TESTDIR" EXEC .bset env 'my_laptop_ISDIRTHERE' = 'C:\Andy' (New Variable) So we see above that BF created a new variable. But if I then try to echo out the value (which should be C:\Andy). I can't do it. None of these work. 1) echo "the value after is: ${BF_SERVER_ISDIRTHERE} " 2) echo "the value after is: ${${BF_SERVER}_ISDIRTHERE} " 3) echo "the value after is: $${BF_SERVER}_ISDIRTHERE " 1) results in undefined variable referenced 2) results in ${my_laptop_ISDIRTHERE} (note that it resoved the inner ${BF_SERVER}) 3) results in ${BF_SERVER}_ISDIRTHERE and in my output log of the steps there is a line that reads: my_laptop_ISDIRTHERE=C:\Andy so I know it's defined. I just can't figure out how to reference it. remember, the name of the variable is created based on the BF_SERVER variable so it's not known to me until the job runs. Andy |
|
I found the same question on DeveloperWorks. Unanswered unfortunately.
http://www.ibm.com/developerworks/forums/thread.jspa?threadID=326799&tstart=15 More examples and a slightly different use case. Same issue though.. Andy |
I found the same question on DeveloperWorks. Unanswered unfortunately. Hi Andy, This solution might work for you if you can assure that the last step below runs on a computer using Windows. The issue is that Build Forge does not do double pass substitution on these variables. Therefore, we'll have to be creative. What the first step does is to create another variable with the value set to the name of ${BF_SERVER}_ISDIRTHERE . The following step then uses the Windows shell environment to get at the new variable's value. .bset env "${BF_SERVER}_ISDIRTHERE=$TESTDIR" "SERVER_VAR=${BF_SERVER}_ISDIRTHERE" .bset env "SERVER_VAR_VALUE=`echo %${SERVER_VAR}%`" The step output would look like the following statements. 8 6/3/10 12:16 PM STEP .bset env "${BF_SERVER}_ISDIRTHERE=$TESTDIR" "SERVER_VAR=${BF_SERVER}_ISDIRTHERE" 9 6/3/10 12:17 PM EXEC .bset env 'S_1_ISDIRTHERE' = 'C:\temp' (New Variable) 10 6/3/10 12:17 PM EXEC .bset env 'SERVER_VAR' = 'S_1_ISDIRTHERE' (New Variable) 8 6/3/10 12:17 PM STEP .bset env "SERVER_VAR_VALUE=`echo %${SERVER_VAR}%`" 9 6/3/10 12:17 PM EXEC .bset env 'SERVER_VAR_VALUE' = 'C:\temp' (New Variable) bju |
|
Hi Folks.
I think I figured this out. Important things....... 1) This is windows. 2) Usually , using $ notation for variables in BF steps on Windows, works just fine. This is example where $ notation on windows came back to bite me. Creating a variable with .bset like this works just fine: .bset "${BF_SERVER}_VAR= `(some command)`" However, referencing it is tough. when I tried referencing it like this: ${${BF_SERVER}__VAR} I got ${Server1_VAR} after BF did the first variable substitution. However, it only did one substitution and passed ${Server1_VAR} to the agent. Of course Windows doesn't know what to do with the $ notation. However, both of these notations worked. %${BF_SERVER}__VAR %%BF_SERVER%_VAR% |
|
bju,
I posted my final findings so thanks for confirming that BF only does one pass for variable substitution. Thanks for the tip on trying a system variable. I was going crazy last night. Andy |
bju <ulbricht> wrote:
This solution might work for you if you can assure that the last step I assume that if you use .tset, they can be done in the same Build Forge step. That uses the fact that all Build Forge variables are put into the CMD environment, though normally it's hard to get to them without Build Forge intercepting the use. If the syntax %...${NAME}...% offends your sensibilities, or you can't use it, you can get at the variable another way. On Windows, for example, set ${BF_SERVER}_ISDIRTHERE>tempfile .edit /${BF_SERVER}_ISDIRTHERE// tempfile This puts the value into a file instead of a Build Forge variable or a shell variable. That may be more or less useful depending on what you plan to do with the value. You can then put it into a Build Forge variable with something like .set env SomeEnv "OtherVar=`type tempfile`" You can instead use FOR /F ... ('type tempfile') ... to get it into a CMD variable. Which shows how to do the trick on UNIXy systems, where you might not be able to do ${...%VAR%...} (I can't test it). You can change the two lines to something like env | sed -e "s/^${BF_SERVER}_ISDIRTHERE=//" > tempfile "eval" can then be used to construct an assignment statement. -- Tim McDaniel, tmcd@panix.com |
|
In article <hvm5db>,
Tim McDaniel <tmcd> wrote: If the syntax %...${NAME}...% offends your sensibilities, or you can't Ack! I copied and pasted from my own code and screwed up the editing. My apologies. It should have removed the equal sign too: set ${BF_SERVER}_ISDIRTHERE>tempfile .edit /${BF_SERVER}_ISDIRTHERE=// tempfile That's because, in Windows CMD, "set {prefix}" emits the definitions of all CMD environment variables that start with {prefix}, and each definition is of the form "NAME=VALUE", even if there's just one variable. For example, on my current system, "set USER" outputs USERDOMAIN=QA-TMCDANIEL USERNAME=tmcdaniel USERPROFILE=C:\Documents and Settings\tmcdaniel -- Tim McDaniel, tmcd@panix.com |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.