"like INSTALL_LOCATION that doesn't exist in the shell." -> do you mean doesn't exist in the shell the blpackage creates for the external commands, or doesn't exist in a login shell. if the later, what is setting the env var if you are not driving the scripts w/ an automation system?
Hi Bill, if you have a Blpakg with 2 ext commands, if the 1st command sets an env. variable (export LOCATION=/tmp), the 2nd ext command has no access to that variable (echo $LOCATION, null), I tested this, it returns a null value.
The scripts that we are pacakging are expecting some sort of a env var to be set, like LOCATION=/tmp for example
Before running the script I wanted to have 1 single ext cmd to set any possible env vars that these scripts are looking for (lets say its 10 vars), so I can reuse this blpkg for every script, so I would have something like this:
1st ext command declares all the necessary env var and then I just replace the actual script object in the blpkg for each script that I need to automate..
and then have the install cmd execute. For any additional scripts, all I have to do is replace the .ksh file in the blpkg but the rest of the items are the same. This wont work because anything following the 1st ext.cmd. has no access to these variables.
The only way this will work is if I move all these env vars to the 'install' ext.cmd at the bottom, and then run everything in the same step. Its very messy way to pass variables because if I have more than 1 install ext.cmd (like Pre-Install or Post-Install), every step needs to have these variables re-initialized.
So how do you normally set these env vars w/o an automation tool ?
the customer is migrating from another automation tool that sets has the ability to set these vars globally before running any packaged scripts. Each subsequent script thats run can see these vars, I think the way it executes the whole thing is in 1 shell session. With a BLPkg each step or ext.cmd. needs to have its vars/properties re-initialized.
We came up w a workaround by basically adding all these env vars into the 'install' step so the script 'sees' the variables when it runs since its part of 1 single ext.cmd. But again, its abit messy.
It’s a good ‘idea’ to create..
You could have 1 ext cmd that dumps the vars to a file and then source the file in each ext cmd before calling the scripts.
You should use Type 3 NSH Scripts to run the ksh scripts, instead of using BLPackages. That's what this type is made for. That way you can pass parameters, and it's executed with nexec under the covers, so it will be just as if your script was called locally by root.
All you need to do, is add the ksh to the depot as a NSH Script, and select the 3rd bullet from the type selection.
EDIT: Sorry I skimmed your question too fast, I see why you need this. What you could do then is to dump the variables to export to a .ksh file, and to source it from the next command. Example:
Ext command 1:
echo "export VAR1=val1" > /tmp/PACKAGE_NAME.exports
export VAR2=val2 >> /tmp/PACKAGE_NAME.exports
Ext command 2:
...do whatever you want next
..and if you can't edit some of the scripts requiring those variables, then just call all your steps from the same external command so they are all spawned by the same shell...