system() command

[Brian K. W. Hook]

In article <obetOdy00UzxA2Ya89 at andrew.cmu.edu> tp1l+ at andrew.cmu.edu (Thomas W. Pope) writes:
|>
|>   I am writing a short program to put into my autoexec file, allowing me
|>to select a shorter autoexec by hitting a key.  For this I tried to use the
|>system() command to run either of two batch files.  The command works fine, but
|>the program stays resident after that call, adding 64k to my memory usage.
|>   The Turbo C manuals say that the system command will run batch files fine,
|>but it seems to terminate withour clearing memory every time I try it...  Does
|>anyone know how I could make these calls from my program???  I have tried the
|>following calls:
|>
|>
|>   system(default)              system(call default)
|>   execvp("default.bat")        execvp("dobat.exe",default.bat")

I know that in DOS if you call a batch file from another batch file that it
will not return unless you state specifically that what you are doing is
calling a BAT file....e.g.

CALL DEFAULT.BAT

Does your program get past the system() command?  If not, then it is likely
that it is getting stuck after that .BAT file....the system() command
executes a command and then returns to the calling process, so I would
presume that you would want to return....if you don't want to return to
the calling process don't use system()....in other words, if you are
chaining your main program to your batch program, without returning to
the main program, don't use system().

Execxx (xx are the various incarnations you can use) should work, but I
am not familiar enough with them....have you considered using errorlevels?
The DOS manual states how errorlevels are used, and errorlevels are very
easy to set with a program...it's simply the return value of main().

E.g. (not sure if syntax is exact)

getbat
if errorlevel==1 call bat1.bat
if errorlevel==2 call bat2.bat

However, I believe that errorlevel evaluates to true if the current errorlevel
is equal to or higher than what you are comparing it to....so that example
isn't exactly correct....

Hope this muddle sort of helped,

comp.os.msdos.programmer might be able to help out a bit more.