Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!iuvax!iucs!bobmon From: bobmon@iucs.UUCP (RAMontante [condition that I not be identified]) Newsgroups: comp.sys.ibm.pc Subject: Re: MSC spawn() problem Message-ID: <4764@iucs.UUCP> Date: Sat, 5-Dec-87 17:09:15 EST Article-I.D.: iucs.4764 Posted: Sat Dec 5 17:09:15 1987 Date-Received: Thu, 10-Dec-87 20:01:47 EST References: <149000015@inmet> <474@silver.bacs.indiana.edu> Reply-To: bobmon@iucs.UUCP (RAMontante [condition that I not be identified]) Organization: Indiana University, Bloomington Lines: 26 creps@silver.UUCP (Steve Creps) writes: >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 >(deleted) > >>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". 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, > > I don't think it's a bug; I think it's a feature, a feature of MS-DOS. >When you spawn a new shell in DOS it should return the environment the same Unless I'm overlooking a smiley here, I have to disagree. When I spawn a subshell out of Procomm I get the offending garbage at the end of the environment space -- and Procomm contains a Microsoft copyright statement. When I spawn a subshell out of microEmacs, which I compiled with Turbo C, I have a nice clean environment. Checking quickly here, I see that the garbage string is 19 (visible) characters long. I guess I could believe that Microsoft intentionally uses 19+ bytes of garbage to mark the end of a block of storage... :-) Can anyone comment on microEmacs' behavior under other compilers?