Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Can this be possible: TCEXIT is not executed?

Jun
22
0
I have a history-saving command in my TCEXIT.btm and recently I recongized that the last change of the history file is from March 2011. So I experimented and took a MSGBOX-command into the TCEXIT, but nothing happened after exiting the TCC-session and, of course, also the history > filename-command has not been executed.
What can be wrong?
 
What can be wrong?
Have you checked the path setting for TCSTART/TCEXIT in the Option dialogs?? Is your TCSTART in the same place?? (I assume that that is getting executed, since it is rather more noiticeable if not)
 
Have you checked the path setting for TCSTART/TCEXIT in the Option dialogs?? Is your TCSTART in the same place??
I have no TCSTART/TCEXIT path settings, they reside in the TCC/TCMD installation directory. TCSTART is executed properly, but not TCEXIT.
Greetings
 
TCC never looks in the installation directory for TCSTART or TCEXIT (because this won't work in Windows 7 or Vista -- they don't allow users to write anything to "\program files\*").

TCC looks in three places:

1) The path specified in OPTION (always a good idea to put your path here)
2) The COMSPEC directory (which may or may not be the same as the installation directory)
3) The root directory of the boot drive.

So you either don't have TCEXIT located in one of those places, or you have a problem with how you're exiting TCC & the contents of your TCEXIT. If you close TCC by typing "EXIT", TCC will always run TCEXIT to completion. But if you're closing TCC by clicking on the X in the title bar (or by clicking on the X in a TCMD tab window), Windows will only allow TCC a brief period of time (about 4-5 seconds) before it forcibly closes TCC. So if you have something in your TCEXIT that takes a few seconds to run, it will never work because Windows kills TCC before TCEXIT can finish.
 
Hi Rex, have not heard from you a long time.
Thx for the answer, I know this sequence out of the documentation. My COMSPEC points to the installation directory. According to this TCSTART is executed properly, its at the same location.
The one & only command in TCEXIT is "history > %_SetDir\HISTORY". %_SetDir is an Environmant Variable set by TCSTART: "C:\Program Files (x86)\TCMD\"\Settings, where the file HISTORY (and the files ALIAS, SETS, FUNCTION) is located to be loaded by TCSTART. I don´t hope that this one command plus expanding it consumes more then 6 seconds.
Furthermore: not even a "pause" is executed when finishing the TCC shell.
I never close the shell via the X in the upper right corner, because this would need to move the mouse, which I do not use when I am in a command window. I have an Alias "x" for Exit, this is much more efficient.
 
I trust you're running XP, because your TCEXIT history redirection will definitely not work in Vista & Windows 7 & Server 2008.

I can only think of two possibilities: either TCC is finding the TCSTART in a different directory (so you're not really running the TCSTART / TCEXIT you think you are), or something is changing COMSPEC between the time you start TCC and the time you exit. (Or a third possibility -- your TCEXIT doesn't have a recognizable executable extension? Are you naming it TCEXIT.BTM or something else?)

Have you tried putting the explicit path in OPTION? That will *always* work, and you won't be reliant on TCC guessing where to find your TCSTART / TCEXIT.
 
I´m running Win7Pro & and why do you think this redirection will not work? If I do it from the commandline explicitly, it works fine.
The right TCSTART is been finded in the directory: I putted a "echo halihalo" just into this one version and it echoed it to me.
Both files have the correct .BTM extension.

I built this batch file; xx.txt has not existed before:

echo %comspec >> C:\Users\WB\Desktop\xx.txt
history >> C:\Users\WB\Desktop\xx.txt
x

This was the output:

C:\Program Files (x86)\TCMD\tcc.exe
echo %comspec >> C:\Users\WB\Desktop\xx.txt & history >> C:\Users\WB\Desktop\xx.txt & x
set
alias
*alias
exit
al
e
cd settings
alias /r alias
dir
alias /r aliases
function /r functions
set /r sets
a
d
u
e xx.btm
xx

As you can see: 1. redirection of the history output has been worked, 2. The COMSPEC ist set properly to the directory where TCC.EXE, TCMD.INI, TCSTART.BTM, TCEXIT.BTM resides.
I then modified the TCEXIT.BTM (just this one) in this way:

history > %_SetDir\HISTORY
echo TCEXIT >> C:\Users\WB\Desktop\xx.txt
history >> C:\Users\WB\Desktop\xx.txt

and ran the batch file again (after deleting the output file xx.txt). This was the output:

C:\Program Files (x86)\TCMD\tcc.exe
echo %comspec >> C:\Users\WB\Desktop\xx.txt & history >> C:\Users\WB\Desktop\xx.txt & x
set
alias
*alias
exit
al
e
alias /r alias
dir
a
d
e xx.btm
list tcexit.btm
cd settings
set /r sets
alias /r aliases
functiin /r functions
function /r functions
u
xx

As you can see, TCEXIT.BTM has not been executed.
 
In the meantime, I created a batch file named insteadoftcexit.btm with this content

history > %SetDir\HISTORY
*exit

an set the aliases "x" and "exit" to this batch file -- works fine!
Greetings!
 
I´m running Win7Pro & and why do you think this redirection will not work?

Your prior posting had you redirecting to "\program files":

"history > %_SetDir\HISTORY". %_SetDir is an Environmant Variable set by TCSTART: "C:\Program Files (x86)\TCMD\"\Settings

and that cannot work unless you've completely disabled UAC.

Did you ever put the TCSTART / TCEXIT path into your TCMD.INI?
 
Note to Rex: If you're thinking about removing some .INI directives in the next version, I'd nominate StartupFile and ExitFile as perfect candidates. They're undocumented, mostly forgotten, and duplicate well-documented functionality (the /I startup option.)
 
...and that cannot work unless you've completely disabled UAC.
Yes, I have it completely disabled.

Did you ever put the TCSTART / TCEXIT path into your TCMD.INI?
No, because I want it to be portable. If it would be possible to use environment variables in the INI, I would do it (and set the appropriate vars before). But, as you can see in all my batches and settings, I strongly prefer using adjustable settings.
But, of course, for testing purposes, I can temporarily do it. I will tell you about the result.
 
No, because I want it to be portable. If it would be possible to use environment variables in the INI, I would do it (and set the appropriate vars before). But, as you can see in all my batches and settings, I strongly prefer using adjustable settings.
But, of course, for testing purposes, I can temporarily do it. I will tell you about the result.
There is one method to set flexible paths in the .INI files.
1/ Specify the START directory explicitly in the shortcut used - mine is F:\JPSOFT.
2/ In all instances where a path is specified, use the "." as the base from which to start.
Note: this works with V13 and all earlier releases. Hopefully Rex will not change it in the future.
 
exitfile=Yes

Another beautiful theory goes down in flames.

Does ECHO "%_TCEXIT" report the expected filename?

Are you using the x86 build of Take Command? If so, does the x64 build have the same issue?
 
Thank you all, the story has an end (at least for the present):

I set (as I wrote in my previous posting) the TCSTART and TCEXIT paths into the INI and, wondering, it worked: TCEXIT was called and executed, although it was the same path as COMSPEC (and as before the whole time).
Then I erased the TCSTART and TCEXIT settings from the INI file again and it continues working! Very strange!
To complete the test, I rebooted my PC (with the TCSTART and TCEXIT not set in the INI), and now it works fine, with exactly the same configurations with which it did not work since the last March. Can You believe it?

So, I do not know, what has exactly happened, nevertheless it is done and over.
Thank you all again and have a very good time!
WB
 
TCC does support expanding environment variables in TCMD.INI (though TCC/LE does not).
Really, I didn´t know this, sorry.
BTW: I don´t find in the helpfile the explanation of all the possible entries of the INI-file, I remember at 4Dos- / 4NT-times they were there. Because I don´t like to set the parameters by the OPTION-dialogue, I prefer the good old texteditor (Real Programmer, you know ;). I only find the key remapping directives (which I do nut use) and the special ones für debugging etc
 
Really, I didn´t know this, sorry.
BTW: I don´t find in the helpfile the explanation of all the possible entries of the INI-file, I remember at 4Dos- / 4NT-times they were there. Because I don´t like to set the parameters by the OPTION-dialogue, I prefer the good old texteditor (Real Programmer, you know ;). I only find the key remapping directives (which I do nut use) and the special ones für debugging etc
You are not the only one who feels this way, but there is a multitude of users who do not want to go through the manual (even if it is interactive) to find all the little things that need to be controlled, and had represented a support nightmare. So for us "techies", it's less convenient, but for the majority of buyers it is better. Can't be all things to all people!
 
Can't be all things to all people!
And why should it not be possible to go both ways? You can edit the INI file via the OPTION-dialogue or using a texteditor. The documentation about the entries can reside in a separate paragraph item and would not be red by the "multitude of users".
 
And why should it not be possible to go both ways? You can edit the INI file via the OPTION-dialogue or using a texteditor. The documentation about the entries can reside in a separate paragraph item and would not be red by the "multitude of users".

You're missing the point -- we dropped support for directly editing of the .INI files because well over 50% of our total support / "bug" issues in Take Command were coming from the "advanced" users mangling their .INI files. A combination of not reading the docs, creating imaginary directives, using the wrong parameters, putting the directives in the wrong section, and creating .INI files in the wrong directories. The novice users used OPTION and never caused any support issues.

That all dropped to near 0 when we removed the directives from the docs and told everyone to set everything in OPTION. The remaining "bug" reports I can now comfortably ignore, since this is now thoroughly documented as unsupported. :)
 
And why should it not be possible to go both ways? You can edit the INI file via the OPTION-dialogue or using a texteditor. The documentation about the entries can reside in a separate paragraph item and would not be red by the "multitude of users".
I will paraphrase what Rex wrote on this topic: so many users do not understand how to edit the .INI text file to their liking that it was a support nightmare. I'd rather have the product with less than full documentation than not have it at all.
 

Similar threads

D
Replies
0
Views
2K
drrob1
D
Replies
1
Views
2K
Back
Top