|
Home > Archive > Unix administration > January 2004 > How to setenv in script?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to setenv in script?
|
|
|
| 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:
quote:
>On Thu, 10 Jul 2003 at 19:32 GMT, pkq wrote:
>
>
>
> It will not be set anywhere; Bourne-type shells (sh, ksh, bash,
> etc.) do not use setenv. Use:
>
>XYZ=xyz
>export XYZ
>
> Also, among Bourne-type shells, only bash and zsh use the source
> command; the standard method is a period:
>
>. mysource
>
>
>
| |
|
| Chris,
sorry, the first line should be :
#!/usr/bin/tcsh
I use tcsh which support setenv.
Thanks
Chris F.A. Johnson wrote:
quote:
>On Thu, 10 Jul 2003 at 19:32 GMT, pkq wrote:
>
>
>
> It will not be set anywhere; Bourne-type shells (sh, ksh, bash,
> etc.) do not use setenv. Use:
>
>XYZ=xyz
>export XYZ
>
> Also, among Bourne-type shells, only bash and zsh use the source
> command; the standard method is a period:
>
>. mysource
>
>
>
| |
| Barry Margolin 2004-01-23, 4:28 pm |
| In article <bekjn7$1j44$1@nntp6.u.washington.edu>,
pkq <wanbo@u.washington.edu> wrote:quote:
>Chris,
>
>sorry, the first line should be :
>#!/usr/bin/tcsh
>
>I use tcsh which support setenv.
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 2004-01-23, 4:28 pm |
| In article <bekjn7$1j44$1@nntp6.u.washington.edu>,
pkq <wanbo@u.washington.edu> wrote:quote:
>Chris,
>
>sorry, the first line should be :
>#!/usr/bin/tcsh
>
>I use tcsh which support setenv.
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.
| |
| James T. Dennis 2004-01-23, 4:28 pm |
| Barry Margolin <barry.margolin@level3.com> wrote:quote:
> In article <bekjn7$1j44$1@nntp6.u.washington.edu>,
> pkq <wanbo@u.washington.edu> wrote:
[QUOTE][color=darkred]
[QUOTE][color=darkred]
> csh and tcsh are poor shells for scripting.
quote:
> 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.
quote:
> If you want your interactive shell to see the environment changes, then you
> must source the script.
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
| |
| James T. Dennis 2004-01-23, 4:28 pm |
| Barry Margolin <barry.margolin@level3.com> wrote:quote:
> In article <bekjn7$1j44$1@nntp6.u.washington.edu>,
> pkq <wanbo@u.washington.edu> wrote:
[QUOTE][color=darkred]
[QUOTE][color=darkred]
> csh and tcsh are poor shells for scripting.
quote:
> 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.
quote:
> If you want your interactive shell to see the environment changes, then you
> must source the script.
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
|
|
|
|
|