Quote:> Observe (under Solaris, using original /bin/sh):
> $ echo $TERM
> VT220
> $ TERM=vt100;echo $TERM
> vt100
> $ exec sh
> $ echo $TERM
> vt220
> This is expected behavior, since I did not export TERM (again) after
> changing it. In fact, steady readers of this newsgroup will recognize that
> this was all hashed out a few months ago - where someone pointed out that
> this behavior isn't 100% consistent - that scripts that depend on it,
> sometimes fail. Most people's reactions at the time were along the lines
> of:
> 1) "Modern" version of sh (ksh, bash, Posix shells) don't do this.
> 2) It was a misfeature in the first place and you shouldn't rely on it.
> Granting all of that, I am still curious about something. That is,
> under what circumstances can it "fail" - that is, have it print out
> VT100 in the last step of the above example? (*) I know that some
> cases (well, at least one case) of this exists, but I can't pin the
> circumstances.
> Any help is appreciated.
> (*) Or, to be more precise, have an exec'd (or fork/exec'd) process get the
> changed value in its environment.
I missed the discussion you refer to (or my memory is going), but I would
expect your last "echo $TERM" to give "vt100" unless TERM were set in
.profile or /etc/profile (or whatever files /bin/sh sources on
invocation).
However, a comparison of two shell man pages (sh on SunOS 4.1.4 and bash
2.05) shows two different behaviours:
SunOS:
Environment
The environment (see environ(5V)) is a list of name-value
pairs that is passed to an executed program in the same way
as a normal argument list. The shell interacts with the
environment in several ways. On invocation, the shell scans
the environment and creates a parameter for each name found,
**** giving it the corresponding value. If the user modifies the ****
**** value of any of these parameters or creates new parameters, ****
**** none of these affects the environment unless the export com- ****
**** mand is used to bind the shell's parameter to the environ- ****
ment (see also `set -a'). A parameter may be removed from
the environment with the unset command. The environment
seen by any executed command is thus composed of any unmodi-
fied name-value pairs originally inherited by the shell,
minus any pairs removed by unset, plus any modifications or
additions, all of which must be noted in export commands.
Bash 2.05:
Environment
When a program is invoked it is given an array of strings
called the environment. This is a list of name-value pairs,
of the form name=value.
Bash provides several ways to manipulate the environment. On
invocation, the shell scans its own environment and creates a
parameter for each name found, automatically marking it for
export to child processes. Executed commands inherit the
environment. The export and `declare -x' commands allow
parameters and functions to be added to and deleted from the
*** environment. If the value of a parameter in the environment ***
*** is modified, the new value becomes part of the environment, ***
*** replacing the old. The environment inherited by any executed ***
*** command consists of the shell's initial environment, whose ***
*** values may be modified in the shell, less any pairs removed ***
by the unset and `export -n' commands, plus any additions via
the export and `declare -x' commands.
In bash "If the value of a parameter in the environment is modified, the
new value becomes part of the environment, replacing the old" whereas in
the SunOS shell, "If the user modifies the value of any of these
parameters ..., none of these affects the environment unless the export
command is used".
In other words, the behaviour is shell-dependent.
--
Chris F.A. Johnson http://cfaj.freeshell.org
===================================================================
My code (if any) in this post is copyright 2001, Chris F.A. Johnson
and may be copied under the terms of the GNU General Public License
by