del@pilchuck.UUCP (02/03/87)
Ok, this is a *workaround* not a solution: Patch the version of command.com that resides in the DV directory to have enough environment space to support all the variables you wish to use. This is the command.com that DV loads, *not* the one in the root directory, *or* the one specified in COMSPEC (I know, I know, yuck). Then just put the SET statements in your startup batch file that you execute when you startup DV. If you absolutely *must* have a copy of the environment that you had when you fired off DV, write yourself a quick and dirty little program (in your favorite programmin' language) that will insert the characters "set " in front of each line it reads from a file, and echo to stdout. Have the rest of the commands you execute on startup in some file which you concatenate to the output of this program. Uh, an example: you wrote the program called SETSET.COM, and default commands are in DVSTART.TXT, then you put this in the batch file from which you invoke DV: set > tmp.out setset tmp.out > dvstart.bat type dvstart.txt >> dvstart.bat del tmp.out dv (of course, if you really know your stuff, you will just write setset to take the environment variables from it's own env. copy, but this example is something any beginning BASIC programmer can do) In your dvstart.txt file you may want to include a set of commands to add the default DV directory to the search path if it is not already there, this is what DV does with the path variable when it gives it to your program. This can be done as follows: path %path%;C:\DV in your dvstart.txt file. NOTE that this command *must* execute from a batch file or it will not work. Finally, lest I leave out the obvious, in the "command to start program" field of the Change Program menu for DV, you set the command to "dvstart". I didn't say it was a good solution, did I? But it does work, because this is exactly what I wanted to do at first. After things settled down, I found I could just put the standard environment variables directly in the DVSTART.BAT file and skip the other stuff (it does slow down the opening of a DOS window by an annoying amount). -- del (Erik Lindberg) uw-beaver!tikal!pilchuck!del
ralf@b.gp.cs.cmu.edu.UUCP (02/13/87)
In article <598@pilchuck.Data-IO.COM> del@pilchuck.UUCP (Erik Lindberg) writes: >Ok, this is a *workaround* not a solution: > >Patch the version of command.com that resides in the DV directory to >have enough environment space to support all the variables you wish to >use. This is the command.com that DV loads, *not* the one in the root >directory, *or* the one specified in COMSPEC (I know, I know, yuck). [description of workaround trimmed] >del (Erik Lindberg) >uw-beaver!tikal!pilchuck!del Ok, this is a *solution*: Since a DOS window is just like any other window, you can tell it what program to load. Thus tell it to load COMMAND.COM (from whereever you want to load it) and *tell it to close on exit*. The COMMAND.COM will inherit whatever environment variables existed before DV got started. I was adding some new programs, and realized that when I launch ProComm from a DesqView window, it *finds it support files* even though they are *not in the current (data) directory*. I have the PROCOMM environment variable set before calling up DV. A little experimentation revealed that loading COMMAND.COM, with a data file directory set (and of course close on exit, so the EXIT command will close the window, just like a normal DOS window) caused the process to inherit all the environment variables. This method will also work with programs that are normally not loaded directly, as you can simply invoke COMMAND with the /C switch followed by whatever the command is (in fact, one of the programs I just added to DV is a batch file, and I used this method). Of course, this rather severely restricts the length of the command. BTW: with this method, a plain DOS window actually opens *faster* than with DV's normal method, since DV doesn't create a batch file for COMMAND to read to set the path and the current directory. +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | ARPA: RALF@B.GP.CS.CMU.EDU "Teaching COBOL ought to be | | AT&T: (412) 268-3053 (school) regarded as a criminal act" | | Snail: Ralf Brown --- Edsger Dijkstra | | Computer Science Department | | Carnegie-Mellon University DISCLAIMER? Who ever said I claimed | | Pittsburgh, PA 15213 anything? | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ -- +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | ARPA: RALF@B.GP.CS.CMU.EDU "Teaching COBOL ought to be | | AT&T: (412) 268-3053 (school) regarded as a criminal act" | | Snail: Ralf Brown --- Edsger Dijkstra | | Computer Science Department | | Carnegie-Mellon University DISCLAIMER? Who ever said I claimed | | Pittsburgh, PA 15213 anything? | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+