Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.unix.wizards
Subject: Re: Export
Message-ID: <13107@bloom-beacon.MIT.EDU>
Date: 29 Jul 89 05:30:38 GMT
References: <29882@cci632.UUCP> <18793@mimsy.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Distribution: na
Lines: 37

In article <18793@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>The Bourne shell (sh), upon startup, copies its environment to an
>internal table.  It also copies it to another table of shell variables.
>The shell variables are all marked `not exported'.
>
>The `export' built-in looks up the name(s) to be exported in the shell
>variable table, and sets the `to be exported' flag.  The `name=value'
>code checks the `exported' flag, and if set, copies the new value into
>the table of environment variables.

Note the following anomaly, which I think is implied by Chris's
description: if a shell "imports" a variable (i.e. it had been
exported in a parent shell), then changes its value, that changed
value is not exported unless an explicit export is done in the
shell within which the value is changed.  Observe:

	$ var=value
	$ export var
	$ sh
	$ echo $var
	value
	$ var=nothing
	$ echo $var
	nothing
	$ sh
	$ echo $var
	value
	$ ^D
	$ echo $var
	nothing

This is a nuisance; I don't know it it's considered a "feature."
The Korn shell (at least the old version I have) "fixes" this
behavior: imported variables are implicitly exported.

                                            Steve Summit
                                            scs@adam.pika.mit.edu