Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site bnrmtv.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!amdcad!amdahl!bnrmtv!connery
From: connery@bnrmtv.UUCP (Glenn Connery)
Newsgroups: net.micro.pc
Subject: Re: where are you after a batch file
Message-ID: <253@bnrmtv.UUCP>
Date: Sun, 9-Feb-86 13:51:24 EST
Article-I.D.: bnrmtv.253
Posted: Sun Feb  9 13:51:24 1986
Date-Received: Wed, 12-Feb-86 06:15:10 EST
References: <440@tekig5.UUCP> <1130@ecsvax.UUCP> <203@intelca.UUCP> <51@gumby.UUCP> <2063@watdcsu.UUCP>
Organization: Bell Northern Research, Mtn. View, CA
Lines: 39

> ...
> 
> Now, a suggestion: why doesn't somebody write a program that either (a) keeps
> the directory stack in the environment, instead of having to have a writeable
> file sitting around on disk and doing disk accesses for directory
> pushing/popping?  Another approach would be a tiny program that gets the
> current directory and then executes a fresh copy of command.com; when you
> exit, the program would restore the current directory and then exit.  This
> avoids scratch files and large environments, but takes up a few K of extra
> ram for the fresh copy of the command interpreter.
> 
> Just some ideas...

The latter is what COMMAND /c should be doing anyway, but I really don't
want to waste the time or memory on this, as well as the fact that it would
mean multiple batch files where I only wanted one.  Also, there are problems
with doing certain things this way--you can't pass back errorlevel across
such things for example.

The former is a great idea, but I've never seen anybody propose a method
for handling this.  You have to remember that when a program is run by
DOS, it is given a COPY of the original environment.  You can write a
program to modify that environment (though it is still unclear how you
know how much space that environment has been allocated, as opposed to how
much it is using).  You could even use Microsoft C 3.0's builtin functions
for doing this.  But when your program exits the old environment will be
restored with none of your changes.

If you were willing to write a shell or something you could do this by
running the program as an overlay instead, but this seems like it would
be tricky, and wouldn't be portable across multiple versions of DOS.  As
well, if you were going to write a shell for this specific purpose, you
might as well just provide the capabilities that DOS left out directly
rather than doing it this way (variables, pushd/popd).

If anybody has any information on this subject I'd be real interested to
hear it.

...Glenn