Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!sri-spam!ames!ucbcad!ucbvax!ucsfcgl!cgl.ucsf.edu!kneller From: kneller@cgl.ucsf.edu (Don Kneller) Newsgroups: comp.sys.ibm.pc Subject: Re: MSC spawn() problem Message-ID: <10533@cgl.ucsf.EDU> Date: Thu, 3-Dec-87 13:00:56 EST Article-I.D.: cgl.10533 Posted: Thu Dec 3 13:00:56 1987 Date-Received: Mon, 7-Dec-87 05:59:24 EST References: <149000015@inmet> Sender: daemon@cgl.ucsf.edu Reply-To: kneller@socrates.ucsf.edu.UUCP (Don Kneller) Organization: UCSF Computer Graphics Lab Lines: 51 In article <149000015@inmet> ronw@inmet.UUCP writes: > >I believe that the Microsoft C Compiler has problems with environment >space when spawn-like library functions are used. Consider: > main() > { > system("command"); > } >When this program is run it spawns the sub-shell properly, but when you >examine the environment variables with the SET command they appear fine >except there is a little string of garbage at the end of the list that >always contains the string ";C_FILE_INFO". The environment variable ;C_FILE_INFO is intentionally added by MSC to communicate the status of file descriptors (which are open, what the translation mode is). This can be used by subprocesses if they need to use files the parent opened. It *may* be true that the MSC startup code removes the ;C_FILE_INFO variable, so MSC programs can't spawn other MSC programs and pass along the file information. Take this with a grain of salt as I'm not sure where I heard or read it. >To make matters worse, if you >attempt to use SET to change old variables or create new ones, they are >placed at the end of the list (after the garbage). When this happens, >they are visible with the SET command but aren't visible to applications. A subprocess gets its own *copy* of the environment. You can modify this copy, but the subprocess can't (easily) modify the copy of the environment of the parent process. I say "easily" since it is doable, but not trivial and certainly not with the MSC putenv() call. I assume you are trying to do something like: system("set FOO=BAR"); system("application"); [ but application can't find variable "FOO" ] Each system() call forks its own subshell, which is "forgotten" when the subshell exits back to the parent. However, if all you are trying to do is put things into the environment for the application to use, you *can* do: putenv("FOO=BAR"); system("application"); The subprocess gets a copy of the parent's environment, which has the variable "FOO" in it as a consequence of the putenv() call. > [ ... ] >Ron Wallace >Intermetrics, Inc. ----- Don Kneller UUCP: ...ucbvax!ucsfcgl!kneller INTERNET: kneller@cgl.ucsf.edu BITNET: kneller@ucsfcgl.BITNET