john edwards wrote:
>
> Hi All
> I must be missing something here!
> I was going to post this question sometime, so it may
> as well be now......
> I am looking for a way of containing variables so that
> they can not be seen globally. The oposite of this
> posting.

CI variables are always job/session in scope.  SH variables are local, but
inherited by children if the variables have been exported.

How about writing your command file as a POSIX SH script?

> I want to preserve the original environment and
> automatically delete all the work variables created in
> a command file. I thought that by going down a CI
> level I would isolate the original level's
> environment, as in UNIX.

Why not make your CI script use unique variable names?  If I'm writing a CI
script called FOO, all of my variable references will start with FOO too, i.e.:

SETVAR FOO_XX "temp value"
SETVAR FOO_YY "another value"
...
DELETEVAR FOO_@

That way FOO's variables won't conflict with any variables in any parent
scripts.

> This is the effect I was looking for:
> !
> !setvar _xx "Original value"
> !showvar _@
> _XX original value
> !xeq command.file
> ..ci
> ..setvar _xx "temp value"
> ..setvar _yy "another value"
> ..showvar _@
> .._XX = temp value
> .._yy = another value
> ..exit
> !showvar _@
> _XX original value
>
> But the result of the final "!showvar _@" is
> _XX = temp value
> _yy = another value
>
> Any suggestions please.

Another approach that comes closer to what you're trying to do would be to have
your command.file do a :SHOWVAR to a temporary file at script entry, and then
at script exit, reformat that :SHOWVAR output into a :SETVAR command file, and
then execute that to restore the original variable values.

> And what is a good use for going down another CI
> level?

Back in the olden days before command I/O redirection (i.e. the < and >
redirect operators) you could accomplish the same thing by running another CI
process as a child, i.e.:

:RUN CI.PUB.SYS;STDIN=inputfile;STDLIST=outputfile;INFO="command"

But today we can just say:

:command <inputfile >outputfile

One reason you might want to run a CI child would be to provide a chance for
manual human intervention.  For example, the system shutdown script I wrote for
cccd.edu would try to shut down everything automatically, but it would loop and
wait for certain things to terminate, and if they didn't terminate within a
fixed number of iterations or a fixed time period, I would run CI.PUB.SYS to
give the operator a colon prompt to manually deal with the situation.  Once the
operator finished entering any manual commands, he/she would enter :EXIT to
resume script execution.

- Mark B.