X-Authentication-Warning: delorie.com: mailnull set sender to opendos-bounces using -f Message-ID: <000001c193fc$3b6c9ce0$c03dfea9@atlantis> From: "Matthias Paul" To: References: Subject: Re: on a related note Date: Thu, 3 Jan 2002 03:08:02 +0100 Organization: University of Technology, RWTH Aachen, Germany MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g032Cmd17118 Reply-To: opendos AT delorie DOT com On 2002-01-02, DONALD PEDDER" wrote: > I wrote a batch file to call several programs (this is with MS-DOS, as > that is what is on the computer I'm using it on - I don't have DR-DOS on > it yet). For some reason the batch-file ceases to execute after the first > program has run, which kinda defeats the purpose of it. :-) I assume you just called the external program by specifying its name without extension and forgot to prepend the call with "CALL". If this would be the case, the batch will be returned control unless you (at any time later) used a batch file to call the original external in a different place. Example: ... myextprg params... REM Batch execution will come back here if myextprg is a .COM REM or .EXE file, but not if it is a .BAT file. Check %PATH%! ... To be replaced by this: ... CALL myextprg params... REM Batch execution will come back here even if myextprg REM is actually a batch file. ... or even better: ... @CALL myextprg params... REM Batch execution will come back here even if myextprg REM is actually a batch file. ... Remember that the same applies to any recursive external references in the myextprg.bat file. As a general rule of thumb, you should keep the good habit to always pre-pend references to externals with CALL, no matter, if this is required at the time you write the batch job. These are difficult to find mistakes when you have to maintain a large set of interwoven batchjobs later. If you cannot guarantee this for all the files involved, an alternative that will also work with pre-DOS 3 issues is to use "COMMAND.COM /C" or better "%COMSPEC% /C" instead of the "CALL". This will always return, but is slower and will temporarily consume some 5 - 10 Kb for a secondary instance of the command interpreter, while CALL is handled internally in the original copy of COMMAND.COM. Hope it helps, Matthias -- ; http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org