Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uwvax!oddjob!gargoyle!mason
From: mason@gargoyle.UChicago.EDU (Tony Mason)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Cannot putenv() in MSC 4.0
Message-ID: <665@gargoyle.UChicago.EDU>
Date: Tue, 19-May-87 09:43:47 EDT
Article-I.D.: gargoyle.665
Posted: Tue May 19 09:43:47 1987
Date-Received: Wed, 20-May-87 04:46:23 EDT
References: <2301@tekgvs.TEK.COM>
Reply-To: mason@gargoyle.uchicago.edu.UUCP (Tony Mason)
Distribution: na
Organization: U. of Chicago, Computer Science Dept.
Lines: 34
Keywords: pushd,popd,putenv,Turbo Pascal,Microsoft C V4.0
Summary: A program has a local environment

In article <2301@tekgvs.TEK.COM> toma@tekgvs.UUCP (Thomas Almy) writes:
>But putenv() does not appear to actually set the environment!  Just the one
>local to the program!  What good is this??
>
>Considering this, the example program in the Microsoft manual (which sets
>the path) is completely worthless.
>
>I suppose I should have known better since Microsoft C's  library is supposed
>to mimic *NIX as close as possible and putenv won't work there either!

This mechanism is rather useful for such obscure things as allowing a program
to control the environment of it's children.  I have used this for
rudimentary security (it actually works quite efficiently), multiple database
handling, path control, etc.

The erroneous assumption is that these routines should modify the parents
environment.  Since each program has its own environment, putenv works on the
current environment.  This environment is then passed onto children, but
disappears when the parent (and all its decendants) go away.

Programs which modify the parental environment (and it can be done fairly
easily in MS-DOS) seem to cause more problems than they are worth.  I don't
use commercial programs that think they can clobber my environment with
impunity (and there are several out there that do!)

Thus, the example Microsoft gives is useful because it allows the PROGRAM to
control its environment - it could take the current path, append a default
directory to it and let the library routines deal with where a file REALLY
is.

Tony Mason
Univ. of Chicago, Dept. of C.S.
ARPA: mason@gargoyle.uchicago.edu
UUCP: ...ihnp4!gargoyle!mason