ronw@inmet.UUCP (12/02/87)
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". 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.
If you exit from the subshell, the garbage disappears. This problem
occurs with Microsoft C 3.0, 4.0, 5.0 with DOS versions 2.11, 3.0, 3.1,
3.2 (I haven't tried 3.3 yet) on NEC, IBM AT, TANDY, and Zenith machines.
Oddly enough, the string of garbage characters is always the same.
Using the SPAWN functions produces the same result. Since I use
applications which spawn subshells that don't exhibit this problem, I'm
assuming that it's MSC's fault. Any suggestions?
Ron Wallace
Intermetrics, Inc.claus@CS.UCLA.EDU (12/03/87)
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... > >Ron Wallace >Intermetrics, Inc. A related experience: I recently incorporated the same code into a program of mine, and en examination of memory revealed that two sub-shells had been loaded, something like command application command command I guess that makes sense, since it ran a shell and passed the command "command" to it, executing another shell. I does seem messy and unecessary though... ( DOS 3.2 ) Claus Giloi
kneller@cgl.ucsf.edu (Don Kneller) (12/03/87)
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
creps@silver.bacs.indiana.edu (Steve Creps) (12/04/87)
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 as before you spawned it, when you return from the new shell. That means a "set" will only have effect within the shell in which it's performed. That ";C_FILE_INFO" is probably something that is set to save the old environment. - - - - - - - - - Steve Creps on the VAX 8650 running Ultrix 2.0-1 at Indiana University. creps@silver.bacs.indiana.edu "F-14 Tomcat! There IS no substitute."
mshiels@orchid.UUCP (12/04/87)
MSC is putting the funny variables in the environment to facilitate passing open files to children. I guess if you bought the library source code you could taeke that feature out. -- Michael A. Shiels (MaS Network Software) mshiels@orchid.waterloo.EDU UUCP: ...path...!watmath!orchid!mshiels
bobmon@iucs.UUCP (RAMontante [condition that I not be identified]) (12/06/87)
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?
dave@westmark.UUCP (Dave Levenson) (12/06/87)
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