It's all about the answers!

Ask a question

Import a variable from a ksh script


Brian LaVelle (1111) | asked Dec 04 '12, 11:10 a.m.
I'm trying to set a variable in Build Forge based on it being set in a script.

This command is running in the script and then the project step
export TAR_FILE=`/bin/echo ....` 

So the step looks like this ...
$CLEARTOOL_WRAPPER "runscript.ksh"
.bset env DUMP_NAME = ${TAR_FILE}

I cannot seem to get this value added into the temporary variable space for the step to set it with .bset.

One answer



permanent link
David Parrott (2123) | answered Dec 12 '12, 6:56 a.m.
I can explain why and I can give you a (perhaps crude) solution.

Why doesn't it work?

 I think there are two issues for you here.

Issue 1
You are not "sourcing" your shell script using a dot (ie  . $CLEARTOOL etc). Your script therefore throws away env vars when it exits, they do not persist into the caller's environment.

But even if you did use a dot, it would not work because...

Issue2
This relates to how Build Forge implements the "command" box for the step. My understanding is that Build Forge actually takes the contents of the command box and breaks them down into subsets, each of which is either one or more contiguous commands intended to run in a shell on the selected server OR one or more contiguous Build Forge "dot" commands. Each subset of commands intended for a shell are put into their own shell script.

So consider the following step:

mkdir /tmp/abc
.bset env "myvar=10"
ls /tmp > mytemplisting
cat mytemplisting
.semget  foobaa

My understanding is that here Build Forge would generate the following four subsets of things to do:

shell script 1:
mkdir /tmp/abc

internal commands to run 1:
.bset env "myvar=10"

shell script 2:
ls /tmp > mytemplisting
cat mytemplisting

internal commands to run 2:
.semget foobaa

It then runs them in that sequence, ie it runs the first shell script, then does the first set of internal commands to run, then runs the second shell script, then does the second set of internal commands.

The consequence for your situation is that Build Forge creates a shell script to call your $CLEARTOOL_WRAPPER command, and when that Build Forge generated shell script exits, your environment variables will get thrown away before Build Forge executes the subsequent internal .bset command. Presumably Build Forge does not "source" its own generated shell scripts.


What solutions are there?

The only one I can think of right now is to make your own script echo the required variable(s) to stdout, and call it within a .set or .bset command as documented in the Build Forge docs under "Using command output to set values".

This works OK but its a bit crude. It has drawbacks, for example if your script might print other stuff to stdout, outside of your control (eg you call someone else's script from yours to set up configuration for example), then you have to make sure you know which line of output to assign into your variable using the [] method. And then if someone changes the script output one day, suddenly you are no longer scraping the right value into your variable. Another drawback is that if you want to gather two or more variables from the output of one script, the only way to do it is to call the script multiple times, each time pulling out the required line. A further drawback is the 256 char limit.

We do this kind of scraping a bit more cleverly, having been bitten by people changing the output lines we are scraping. We now make just one call to a script, getting it to output to a file using redirection, printing things in a very clear "var=value" sort of way. In a subsequent command we call a custom perl script using .bset, to retrieve one var=value from the file and return its value to be assigned with .bset.

Something along the lines of:

generate_some_stuff.sh > the_stuff.txt
.bset env "var1=`get_var_value.pl file=the_stuff.txt varname=TAR_FILE`"


Hope that helps!
David

Comments
Jirong Hu commented Jun 26 '15, 11:22 p.m. | edited Jun 26 '15, 11:24 p.m.
Hi David

I used the following code but get a weird result. Why are these numbers (underlined).? The output should just be "UARK".
183  06/26/15 11:08PM  STEP  .bset env "APP_NAME=`perl /u/bldforge/Unix.pl GetValue APP_NAME`"
184  06/26/15 11:08PM  EXEC  .bset env 'APP_NAME' = 'UARKD3E6-9173-1016-A2C5-EBCB9B5DE6D8'

    

 .bset env "APP_NAME=perl /u/bldforge/Unix.pl GetValue APP_NAME"


if (uc($name) eq "APP_NAME") {    
      print $env_var{APP_NAME};  
   }

%env_var = CreateHash($g_ENV_VAR);
my $app_name = $env_var{APP_NAME};
print ("\$app_name=$app_name\n") if $debug;


Jirong Hu commented Jun 27 '15, 6:57 p.m.

 @David Parrotthow to write this step command if the server is Windows?

.bset env "var1=get_var_value.pl file=the_stuff.txt varname=TAR_FILE"

Your answer


Register or to post 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.