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