Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cwjcc!gatech!udel!princeton!njsmu!mccc!pjh From: pjh@mccc.UUCP (Pete Holsberg) Newsgroups: comp.unix.wizards Subject: Re: Export Message-ID: <449@mccc.UUCP> Date: 30 Jul 89 16:14:46 GMT References: <29882@cci632.UUCP> <18793@mimsy.UUCP> <13107@bloom-beacon.MIT.EDU> Reply-To: pjh@mccc.UUCP (Pete Holsberg) Distribution: na Organization: The College On The Other Side of U. S. Route 1 Lines: 23 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: =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