.bset env variables only apply to the step in which it's defined and used. Use .set to create and env variable that will be retained.

In article <i0049p>,
jsimon963 <jeffery> wrote:

bset env variables only apply to the step in which it's defined and
used.

No, those are .tset variables that you're thinking of.
..bset variables have effect from the start of the next step and
persists to the end of the job.

See the builtin help article "Changing environment variable values
during a job". It explains some of the differences. That particular
page doesn't explain what is done for inline or chained projects;
while it's explained elsewhere, I found it confusing enough that I
experimented to find out.

(The builtin help for .bset says "The change takes effect immediately
in the current step.". That statement is false.)

--
Tim McDaniel, tmcd@panix.com

In article <i00ibj>,
woodm <woodm> wrote:

Even when I .bset and echo it out in the same step I saw that it
wasn't being set.

..bset doesn't take effect until the next step.

I think this is a result of the fact that when I go
to populate the variable from another shell variable it creates a new
environment to perform the .bset in, losing the shell variable:

example step:

if ; then
VARIABLE1="cell1"
fi
if ; then
VARIABLE1="cell2"
fi

echo "var1 $VARIABLE1" <---- this works
.bset env "DESTINATION=`echo $VARIABLE1`" <---- this doesn't

/example step

I suspect the forum <-> newsgroup gateway is stripping leading periods
from lines. V. annoying. I put it back.

I don't see how
echo "var1 $VARIABLE1"

would work in general. Are you very sure of that? Unless you turn
off Build Forge variable interpolation, I would expect Build Forge to
substitute for $VARIABLE1 when it reads the command block, taking away
your chance to grab the shell variable value.

DESTINATION doesn't get populated. I'm guessing this is because a
bset command starts over with a new environment? So then $VARIABLE1
wouldn't exist there.

If I put the .bset command into the if/then blocks it causes a
problem there saying something to the effect of unexpected end of
file. I'm guessing this is because the .bset exits the executing
script/environment to run itself in its own environment?

I've seen the same thing, and that's my understanding. My mental
model, which has fit my experiences, is that the agent reads each line
of input like this:

if the line starts with "."
process it
otherwise
accumulate lines until EOF or until the next dot command
run those lines as a single command file
(shell script or BAT file)

Also, there's a lot of overhead, if nothing else in log lines, in
starting one of those shell blocks.

So I make a point of grouping dot commands as much as possible, and
not in the middle of shell blocks where I want variables to last.
In particular, I always try to have my .rem lines at the start or
end, or use REM in my CMD blocks (I would use "#" in UNIXy shells).

I have some idea's for workarounds.
-put this if/then logic into an external shell script.
-put this if/then logic into the .bset command itself (.bset env
"DESTINATION=`if ... then fi if .....`

- put the if/then logic into condition steps in Build Forge.
Not very practical unless there are very few choices,
because you need a step per conditional and those appear to have
large overhead.

- what I have done: put shell variable values into the filesystem.
Dot commands *can* see them.

] set XYZ=...an expression...
] set XYZ>tempfile
] .edit /XYZ=// tempfile
] .tset env "bsetVariable=`type tempfile`"
] del tempfile

Or similarly for a UNIXy shell, except you grab the value via
] set | grep '^XYZ='>tempfile

--
Tim McDaniel, tmcd@panix.com

In article <i0b62g>,
Tim McDaniel <tmcd> wrote:

In article <i0049p>,
jsimon963 <jeffery> wrote:
bset env variables only apply to the step in which it's defined and
used.

No, those are .tset variables that you're thinking of.
.bset variables have effect from the start of the next step and
persists to the end of the job.
....
(The builtin help for .bset says "The change takes effect immediately
in the current step.". That statement is false.)

I don't know how I came to write that. .bset does take effect
immediately, in my retest in Build Forge 7.1.1.4 on Windows.
My apologies.

My structure was
(1) .bset env "VAR=423"
then use ${VAR} in a .tset, echo it in commands.
another dot command block with .tset using ${VAR},
echo it again
(2) inline step: echo ${VAR}
(3) pass chain: echo ${VAR}
(4) step: echo ${VAR}
(5) inline: echo ${VAR}
(6) pass chain: echo ${VAR}

With .bset, the variable setting took effect at once and held for the
rest of the project *except* that (3), the immediate pass chain,
didn't see the value.

If I instead did
(1) .tset env "VAR=423"
it did what I had previously found: it was available in (1), (2), (3),
but not (4), (5), (6).

--
Tim McDaniel, tmcd@panix.com