Hello,

I want to setup some environment variables in a script:

#!/bin/sh
echo setenv XYZ xyz > mysource
source mysource


But after the running of the script, the env XYZ has not been setup yet.
The XYZ can be setup if I just type in the commands.

Do you have any idea on how to keep it after the script?

Thanks,
Bo

Chris,

sorry, the first line should be :
#!/usr/bin/tcsh

I use tcsh which support setenv.

Thanks



Chris F.A. Johnson wrote:

In article <bekjn7$1j44$1@nntp6.u.washington.edu>,
pkq <wanbo@u.washington.edu> wrote:
csh and tcsh are poor shells for scripting.

Anyway, the script should work if it uses tcsh. But the environment
variable will only be set in the shell that's executing the script. When
that shell exits, you'll be back to your interactive shell, which isn't
affected.

If you want your interactive shell to see the environment changes, then you
must source the script.

--
Barry Margolin, barry.margolin@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

Barry Margolin <barry.margolin@level3.com> wrote:
Specifically consider this: when you run any external command (any
command, whether it's a binary or script) you've implicitly created a
subprocess. That subprocess has a COPY of your environment, which it can
modify. However, changes to a child process' environment don't affect
the parents. It's a COPY.

Only an built-in command (such as 'read', 'set' or 'unset') or operator
(such as = --- for variable assignments) can modify a shell's own
environment.

When you source a file (or eval a string) those changes occur within the
current process. Those commands are read and interpreted by the current
shell process as though you'd typed them.

Incidentally there is a subtly you should be aware of if you're going to
learn shell scripting. consider the following:

unset bar; echo foo | read bar; echo $bar

We see a sequence of three commands, unset (internal), echo (could be
internal or external, depends on the shell), read (must be internal) and
another echo. The unset is in the current process. The echo | read
is interesting because ANY PIPE CREATES AN IMPLICIT SUBSHELL, and then the
'echo $bar' -- might be internal or external.

The key question here is will $bar be set to foo subprocess created to the
left of the pipe, or unset (suprocess was created to the right of the
pipe, and ends/exits at the semicolon.

(The answer depends on your shell. Korn shell 88 or later, and zsh do it
*correctly* --- reading values *into* the current process by creating
subprocesses to the left of each pipe. Bash and some other's to it
"wrong" forcing us to use backticks and subprocess braces and other
hackery).

(The problme is easy with just one value and variable; just use the
command substitution --- backticks; it get's uglier when you want to:

do_something | read a b c d ; ....

you need to:

do_something | { read a b c d ; .... ; }

or:

do_something | ( read a b c d ; .... )

... to force all processing to occur in the subshell

--
Jim Dennis,
Starshine: Signed, Sealed, Delivered