Why does my tcstart.btm sometimes terminate tcc.exe?

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
Here is my tcstart.btm. When I start up a new TCC.exe window, sometimes it runs to completion, leaving me a new TCC window, and sometimes it simply goes POOF! I added debugging to it so I could tell when it's exiting, and when it fails, it's always after creating debugJPc.txt. That makes no sense at all to me, especially since it creates JPc and then JPd consecutively, with no other code in between them. But that is the cessation point, every time. Yet sometimes it runs to success.

Note also that if I remove tcstart.btm from the TCMD directory, TCC always starts up with no problems.

Any ideas what might be wrong, or how I might better troubleshoot it?

@echo off
: This is executed each time a copy of TC/4NT is loaded. You can also create
: TCEND.BTM (4END.BTM) to execute when TC/4NT is exited.
on error gosub ErrorHandler
echo Executing %0
pushd %@path[%comspec]
echo a > c:\wip\debugJPa.txt
unalias *
echo b > c:\wip\debugJPb.txt
alias /r %@name[%comspec].als
echo c > c:\wip\debugJPc.txt
echo d > c:\wip\debugJPd.txt
unfunction *
function /r %@name[%comspec].fns
if exist %COMPUTERNAME%.fns function /r %COMPUTERNAME%.fns
echo e > c:\wip\debugJPe.txt
iff %@name[%comspec] == TCC then
rem remove zip and unzip internal commands
setdos /i-zip
setdos /i-unzip
echo f > c:\wip\debugJPf.txt
iff "%@search[FixPrompt.btm]" != "" then
call FixPrompt
set titleprompt=`%_cwd`
prompt [$t]-$g
echo g > c:\wip\debugJPg.txt
set COLORDIR=offline: black; hidden system:bright red; rdonly: bright black; dirs:bright green; com exe bat btm cmd vbs vbc js:bright yellow; zip arc arj lha cab tar z:bright magenta; c cs cpp h hpp rc odl mc frm bas cls ctl rul wbt:bright white
echo h > c:\wip\debugJPh.txt
set .vbc=%SystemRoot\system32\cscript.exe /nologo
if "%@search[isdev.exe]" != "" set .ism=start %@MaybeQuote[%@search[isdev.exe]]
echo i > c:\wip\debugJPi.txt
if %@instr[0,1,%@verinfo[%comspec%]] GT 6 alias pdir=*pdir /d
echo j > c:\wip\debugJPj.txt
if exist %COMPUTERNAME%.als alias /r %COMPUTERNAME%.als
echo k > c:\wip\debugJPk.txt
if (%_transient == 1 .OR. %_pipe == 1) quit
echo l > c:\wip\debugJPl.txt
if "%@search[env.btm]" != "" call env.btm
echo m > c:\wip\debugJPm.txt
rem no need to worry about restoring drives on second TC/4NT window
REM tasklist tcc > clip:
REM iff "%@clip[1]" == "**EOC**" then
REM call RestoreDriveMappings
REM endiff
setarray _TCCinstances[10]
echo %@execarray[_TCCinstances,tasklist tcc] >& nul
iff %_EXECARRAY == 1 then
call RestoreDriveMappings
unset /q _TCCinstances
echo n > c:\wip\debugJPn.txt
kill c:\wip\debugJP*.txt
echo Error received: ? = %?, _? = %_?, _SYSERR = %_SYSERR
My guess why log file c is created but d is not when TCSTART fails is delayed write - the command is queued for the OS to perform, but the process is cancelled already. I would try using the LOG command to create a command log in a single file.

Do you use global functions or aliases (with or without SHRALIAS)? If you do, the UNFUNCTION and UNALIAS commands will kill all functions and aliases in all other concurrent command processor instances, and reloading the standard set will not restore any created by either batch files or interactively in those instances, possibly causing malfunctioning of their currently running batch programs. OTOH, if you use only local functions and aliases, there will be none loaded before 4START/TCSTART is executed, so the unfunction and unalias commands are unnecessary. The exception is a pipe instance; if you use local functions/aliases your program will ensure that any functions or aliases defined in the parent instance after its xSTART command was executed are NOT propagated into the instance on the right side of the pipe. However, I do not recall a single instance in my many years of using 4DOS+ where I wanted that to happen.

BUG: You create an array _TCCInstnces correctly, but use unset instead of unsetarray.

Some other observations:

1/ 4EXIT/TCEXIT is the command automatically executed on command processor termination, NOT TCEND/4END.

2/ you did not report the command processor version where your TCSTART fails, but it is obviously designed for current and older versions.

3/ As Rex inferred, one of the alias files you load may change a command later in the batch file from being an internal command to an alias. I am sure you realize this can be easily avoided by using e.g. *function instead of function.

4/ You could use the single command for all command processor versions
if isinternal zip setdos /i-zip /i-unzip
(you can even drop the test, SETDOS does not detect an error when you attempt to disable a nonexisting command on the principle that it just did not need to do anything to achieve your goal).

5/ If any of the mapped drives are removable ones, or any of the systems on your network are removable (e.g., laptops), the drive remapping may be required when a command processor instance has previously been mapped already. There is a current thread in this Forum related to detecting disconnects that is still active.
Lots of good feedback. Hasn't solved my problem yet, though. :(

OK, I've incorporated lots of what you suggested.
  • I've been using 4nt version 6.01.245 since it first came out (and of course was using 4dos for years before that), but never upgraded beyond that version until this past month. I use TCC on my main development machine, but still have 4nt on all of my other build machines. I have tried to maintain compatibility with my aliases and functions between them wherever possible. The TCC version is 15.01.52, the latest available.
  • Kept the echo > ... stuff, but added a LOG statement at the beginning of the file. Strange, because no log file is getting created. Did I do it wrong?
  • I use local aliases. Sometimes different windows need different definitions, or I temporarily modify them. So that shouldn't be causing the problem.
  • I do use pipe operations. I'm not quite clear on the implications of local or not, but I've never in my many years of 4nt usage had a problem.
  • Fixed the UNSET versus UNSETARRAY, and the EXIT versus END strings in my comments. Good catches.
  • Updated the SETDOS to the simpler syntax.
  • The network drives are rather unreliable. Our network is horribly flaky, and sometimes I can see them, sometimes not. The thread that you mention in that regard - is that the one called "Handle unexpectedly inaccessible CWD"?
  • comspec environment variable is set to "C:\Program Files (x86)\JPSoft\TCMD\tcc.exe", in case that wasn't obvious.
  • [edit] I forgot to add that when those debugJP<letter>.txt files are created in the C:\WIP folder, I noticed that the contents of ...a and ...b had the single letter a and b, respectively (as expected), but ...c was a zero-byte file.
OK, I'll use the file upload method for my revamped (but still not fixed) tcstart.btm, and also my alias files.