tvf@cci632.UUCP (Tom Frauenhofer) (07/27/89)
<I think this is a wizardly question...> How does the shell mechanism to export a variable work? Are there two environment lists, one public, one private, that a given process uses? Just curious, that's all... Thomas V. Frauenhofer ...!rutgers!rochester!cci632!ccird7!tvf *or* ...!rochester!cci632!ccird7!frau!tvf *or* ...!rochester!rit!anna!ma!tvf1477 FRAU BBS: (716) 227-8094 2400/1200/300 baud - log in as "new" to register "The Earth? I'm going to blow it up. It obstructs my view of Venus" - Martin
chris@mimsy.UUCP (Chris Torek) (07/28/89)
In article <29882@cci632.UUCP> tvf@cci632.UUCP (Tom Frauenhofer) writes: >How does the shell mechanism to export a variable work? Are there two >environment lists, one public, one private, that a given process uses? 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. Thus, inside sh, there are three tables: - the initial environment (on the stack above main()'s frame) - the environment for new processes - all shell variables (Some of the storage for the strings is shared.) Most processes have only the first. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
scs@adam.pika.mit.edu (Steve Summit) (07/29/89)
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
pjh@mccc.UUCP (Pete Holsberg) (07/30/89)
In article <13107@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:
=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:
<Omitted: examples of "global" and "local" variables>
=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.
It seems to me to be quite reasonable. A variable defined in a subshell
(such definition occurring during an assignment) will not collide with a
global (i.e., exported) variable having the same name. Sounds like what
is done in a couple of widely used programming languages.
--
Pete Holsberg -- Mercer College -- Trenton, NJ 08690
...!rutgers!princeton!njsmu!mccc!pjh