Path: utzoo!utgpu!water!watmath!clyde!burl!codas!mtune!westmark!dave
From: dave@westmark.UUCP (Dave Levenson)
Newsgroups: comp.sys.ibm.pc
Subject: Re: MSC spawn() problem
Message-ID: <285@westmark.UUCP>
Date: 6 Dec 87 05:09:25 GMT
References: <149000015@inmet>
Organization: Westmark, Inc., Warren, NJ, USA
Lines: 36

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 the following
> program:
>  
> 	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"...

This is documented in the Microsoft C Users Guide.  The environment
variable named ;C_FILE_INFO contains a binary representation of the
modes (O_TEXT vs. O_BINARY) of each open file that is to be
inherited by the spawned process.  This is invisible to the
environment of the child process if the child process also runs a
Microsoft C program -- that is, the C startup helper that imports
the inherited environment does its thing with the open file handles,
and then makes the ;C_FILE_INFO variable invisible to the getenv()
call in the same process.

The only thing wrong with this scheme is that the child process may
not be written in MS-C.  If it's command.com, as in your example,
then the binary "garbage" remains visible, and may get in the way of
variables which get added to the environment later on.  I think this
is your problem.
-- 
Dave Levenson
Westmark, Inc.		A node for news.
Warren, NJ USA
{rutgers | clyde | mtune | ihnp4}!westmark!dave