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