WAD _exit returns invalid code under some conditions

May 20, 2008
3,515
4
Elkridge, MD, USA
In the TCC instance which issued the REBOOT command causing termination of a session the value of _exit in TCEXIT is 0 ("normal") instead of the appropriate code reflecting the reboot option. Other instances of 4NT and TCC that are also terminated by the logout process report the correct codes.
 

rconn

Administrator
Staff member
May 14, 2008
12,344
149
In the TCC instance which issued the REBOOT command causing termination of a session the value of _exit in TCEXIT is 0 ("normal") instead of the appropriate code reflecting the reboot option. Other instances of 4NT and TCC that are also terminated by the logout process report the correct codes.

I have no idea what you're referring to -- REBOOT is always going to result in a 0 exit code -- unless the REBOOT fails, in which case you'll get a 1 (usage error) or 2 (error exit) return.
 
May 20, 2008
3,515
4
Elkridge, MD, USA
I have no idea what you're referring to -- REBOOT is always going to result in a 0 exit code -- unless the REBOOT fails, in which case you'll get a 1 (usage error) or 2 (error exit) return.
I mentioned nothing about the exit code of the REBBOT command. I am discussing the value of the internal variable _EXIT when TCEXIT is performed. If the last command executed in instance X of TCC is the REBOOT command with one of the options /L, /P, /R or /S, the value of _EXIT is 0 in instant X, instead of whatever is appropriate accoring to the REBOOT option used. However, other instances of TCC or 4NT also terminated due to executing the REBOOT command in instance X, the value _EXIT in these other instances correctly matches the REBOOT option.
 

rconn

Administrator
Staff member
May 14, 2008
12,344
149
I still don't understand your point.

First, %_exit will always be 0 in instance X (provided there isn't an error in your REBOOT syntax). Second, the %_exit value in every other TCC instance will be whatever their last internal or external command returned (unless you have an "ON CLOSE / ON SHUTDOWN / ON LOGOFF" handler defined), and is unrelated in any way to REBOOT. There is no value of _EXIT that "correctly matches the REBOOT option".

So your first instance is closed by the REBOOT command, and all of your remaining instances are closed by Windows, and the exit codes will be random at best, and determined by whatever those shells were doing and what you might have in your TCEXIT.
 
May 20, 2008
11,400
99
Syracuse, NY, USA
I still don't understand your point.

First, %_exit will always be 0 in instance X (provided there isn't an error in your REBOOT syntax). Second, the %_exit value in every other TCC instance will be whatever their last internal or external command returned (unless you have an "ON CLOSE / ON SHUTDOWN / ON LOGOFF" handler defined), and is unrelated in any way to REBOOT. There is no value of _EXIT that "correctly matches the REBOOT option".

So your first instance is closed by the REBOOT command, and all of your remaining instances are closed by Windows, and the exit codes will be random at best, and determined by whatever those shells were doing and what you might have in your TCEXIT.
I don't understand. What about these:
Code:
_EXIT returns the reason for exiting TCC.  The possible values are:
0        EXIT command
2        CLOSE_EVENT
5        LOGOFF_EVENT
6        SHUTDOWN_EVENT
 
May 20, 2008
3,515
4
Elkridge, MD, USA
Internal variable _exit has nothing to do with command exit codes according to the documentation, quoted below (unchanged since V7):
_EXIT returns the reason for exiting TCC. The possible values are:
0 EXIT command
2 CLOSE_EVENT
5 LOGOFF_EVENT
6 SHUTDOWN_EVENT

My observation is that the above correctly documents 4NT/TCC operation for all instances but X, contrary to your statement above. As you stated, in instance X the value is always 0 - which behavior is contrary to the quoted documentation. The difference between documentation and operation is, IMHO, a B U G !
 
May 20, 2008
3,515
4
Elkridge, MD, USA
PS: I wrote my note concurrently with Vince but he posted first... And I would also like to know whether or not my interpretation of the REBOOT command options /R, /S and /P below are correct:

/P perform Windows shutdown, turn off system power (if power supply is controllable by Windows)
/R perform Windows shutdown, immediately restart system
/S perform Windows shutdown, do not turn off power - most systems will automatically restart, not guaranteed

Presumably each of these is a SHUTDOWN_EVENT.
 

rconn

Administrator
Staff member
May 14, 2008
12,344
149
Irrelevant -- your "instance X" (the one that ran the REBOOT command) has exited long before Windows could pass it a shutdown request message. It could only affect instances of TCC that are still running.

To do what you want (keep instance X running after the REBOOT, so it could be shut down by Windows) is not alllowed in Windows.

This is 15+ year old behavior; it is entirely WAD and cannot be changed.

And the entire argument is 90% meaningless in anything newer than XP, since Windows will not allow any of those operations unless you're running an elevated session. REBOOT is essentially obsolete.
 
May 20, 2008
11,400
99
Syracuse, NY, USA
Internal variable _exit has nothing to do with command exit codes according to the documentation, quoted below (unchanged since V7):
_EXIT returns the reason for exiting TCC. The possible values are:
0 EXIT command
2 CLOSE_EVENT
5 LOGOFF_EVENT
6 SHUTDOWN_EVENT

My observation is that the above correctly documents 4NT/TCC operation for all instances but X, contrary to your statement above. As you stated, in instance X the value is always 0 - which behavior is contrary to the quoted documentation. The difference between documentation and operation is, IMHO, a B U G !
Then the whole thing makes sense. The instance receiving the REBOOT command, knowing it would later be asked to terminate, terminates normally (EXIT,0). Since it didn't wait for SHUTDOWN_EVENT, it would be wrong to report that that event was received. Would a new value indicating I_INITIATED_SHUTDOWN_SO_I_TERMINATED_MYSELF_GRACEFULLY be of any value?
 
May 20, 2008
3,515
4
Elkridge, MD, USA
I agree with Vince that what I observe makes sense. However, since instance X does perform TCEXIT, in which it can report the value of _EXIT in a log, I'd like its value to be set to a value indicating that neither EXIT nor an external event, but a local REBOOT caused the termination. However, esp. in view of the restriction of using REBOOT in Vista and later, I think just changing the documentation would be sufficient.

On my systems I log the starting and stopping of each command processor instance, and also the calls to the REBOOT command. I do have the means to determine which (EXIT vs. REBOOT) invoked TCEXIT.

Rex,
do any of REBOOT options /H, /K, /L or /W require elevated TCC in Vista et al.? Would not make sense to me... but then all I have is a PERSONAL COMPUTER, not a BOSSING ME AROUND COMPUTER.
 
May 20, 2008
3,515
4
Elkridge, MD, USA
Thanks. By following the methods in this and other posts in this Forum I succeeded in creating an account on my newly started Win7/64 system where I can run TCMD/TCC elevated, and where the REBOOT command works as it does on WinXP, just as documented.
 
Similar threads
Thread starter Title Forum Replies Date
S How to? Runs start /w in invisible mode OR run program after exit of another one Support 3
vefatica ON EXIT? Support 8
P exit /b in batch files Support 7
rps Reboot and exit reason Support 10
vefatica Exit code of a batch file? Support 4
H lua Causes Take Command Tab to Exit Support 5
Stefano Piccardi MKLNK exit status Support 9
ed neff How to? exit TCC/Take Command to a new directory Support 10
M Why is the exit code zero? Support 6
SeoulBigChris Save Environment (Tabs) on Exit? Support 3
Stefano Piccardi EXIT hangs Support 5
R TC 13 / Using TCDIALOG to exit commands Support 4
M Not real important but kind of annoying EXIT issue... Support 20
lassevk exit(1) in a python script exits console, by design or bug? Support 1
cgunhouse IDE Crashes on Exit Support 6
J tcmd.exe/tcc.exe appcrash on exit Support 4
F %@regex["^-","-a"] returns 0, "^-" =~ "-a" is false (no match) Support 4
Peter Murschall %_BATTERY returns 0 and others Support 9
W pdir returns diff results between tcc and tcmd - one is an error msg Support 5
M Fixed PSHELL command returns error Support 2
H Fixed DIR /G returns wrong sizes Support 2
D COPY returns ERRORLEVEL 2 Support 5
Steve Pitts WAD @MD5 returns incorrect results for strings Support 2
G WAD _DOS and VER/r returns incorect value Support 2
R Function #IDOW returns only 2 characters Support 10
D @IPADDRESS[] always returns 11001 Support 8
vefatica Fixed @FILEOPEN returns 4294967295 Support 2
I Possible Bug: History /n Returns Nothing Support 3
M %_ADMIN always returns 0 Support 3
B Bdebugger doesn't recognize breakpoint after batch file returns Support 2
N Delay returns immediately Support 20
B %ProgramFiles(x86)% returns different values in TCC and CMD Support 3
J BUG: MSGBOX after DETACH returns early with 0 on Win7 Support 3
Joe Caverly @SMWRITE invalid handle Support 8
Chen Touboul When i try to delete an empty folder i got "the dirctoy name is invalid" Support 3
thorntonpg option /u not working The directory name is invalid Support 5
Alpengreis Fixed New INI directive "ANSIWin10" is invalid Support 2
T Invalid attach tabs list Support 10
gschizas Fixed Cannot use extended path to delete invalid file Support 3
jbanaszczyk Invalid client configuration file Support 6
tmaynard Invalid item name "Lua" Support 6
Stefano Piccardi Issue: MKLINK /J creates invalid link [TCC 14.03.53] Support 4
M Why is an obviously invalid file name allowed? Support 2
T TCC reading TCMD.INI causing "Invalid item name" warnings and pauses Support 2
S Fixed BDEBUGGER died on invalid watch request Support 4
fromano Invalid parameter 12.0.34 x64 Support 1
P Help > Update triggers invalid configuration Support 3
David McClelland TC10 - cdd /t gives invalid parameter Support 2
B Invalid updates configuration file. ?? Support 2

Similar threads