ar12@prism.gatech.EDU (REGISTER,ANDREW H) (02/22/91)
Okay, here goes. The way I understand it is that there is a dos imposed line limit for setting environment variables from the command line (or batch files) and this line limit is significantly less than the environment string limit. If this is the case, you should be able, under program control, to append a directory to the end of your path environment or to set a longer environment string than the command line will permit. In order to do this you need to be able to get to the *global* environment storage area. The reason this is not as simple as it sounds is that it seems that when you run a program, a copy of the environment is used while the program is running. For instance if you use some of the turbo c commands to fiddle with the environment, it is changed until you exit from the c environment. On exit, the environment is back to the way it was! Same is true if you run the compiled program from the command line. Does anyone know the address that the operating system keeps the pointer to the beginning of the global environment or some way to find the address for the beginning. What I really want to do is to write a program that I can say something like: SetPath c:\exe^ d:\exe^ and the program will serch for subdirectories (all of them) underneath c:\exe and d:\exe and add them to the path. Sure would be easier than maintaining a long path in autoexec! Any help will be greatly appreciated. Also any suggestions for appropriate cross posting would be helpful Toodles Andy
mir@opera.chorus.fr (Adam Mirowski) (02/28/91)
In article <22549@hydra.gatech.EDU>, ar12@prism.gatech.EDU (REGISTER,ANDREW H) writes:
%% What I really want to do is to write a program that I can say something like:
%%
%% SetPath c:\exe^ d:\exe^
%%
%% and the program will serch for subdirectories (all of them) underneath
%% c:\exe and d:\exe and add them to the path. Sure would be easier than
%% maintaining a long path in autoexec!
%%
%% Any help will be greatly appreciated.
%% Also any suggestions for appropriate cross posting would be helpful
I have choosen another solution. I have most of executables in a single
directory, along with a (text) file which mentions which file belongs to
which package and also memorizes its attributes. An utility I wrote can
insert a package to that directory, extract one to a separate one,
or backup it. A simple TYPE lists them all.
I use it for packages like DOS, MKS toolkit, Norton Utilities/Commander
which are basically batches of loosely coupled executables. I give a separate
directory to "bigger" packages, like Turbo C. That makes a PATH variable
of 4-5 components, quite easy to maintain. No need worrying about why
doesn't the second copy of command.com inherit the environment size of
his parent, etc.
That also enables me to classify various small PD utilities according
to their purpose (about 20 types), while keeping them in a single
directory.
Of course, there are built-in securities that prevent from overwriting
files when two packages have a file with the same name, that check the
file size/time/date/attributes when deinstalling a package, check and
report missing files; the list file is also read-only. The executable
is under 20K.
--
Adam Mirowski, mir@chorus.fr (FRANCE), tel. +33 (1) 30-64-82-00 or 74
Chorus systemes, 6, av.Gustave Eiffel, 78182 Saint-Quentin-en-Yvelines CEDEX