Reload tcmd.ini from the command line
- Thread starter nickles
- Start date
- Jun
- 223
- 0
Suppose I change my ColorDir settings in tcmd.ini. Every time I do that I have to close and reopen my TCC window just to see the effects of the change (just a sample). Using OPTION and changing the ColorDir setting there (the input box for this option is by far too small btw.) would rewrite my tcmd.ini (which I do not want, as it "scrambles" the file).
Also, the current solution offers a very complicated working cycle for a console-oriented person; in Unix shells (probably you should once compare TCC to zsh ;-) reloading can be accomplished from the command line with just a keystroke.
Also, the current solution offers a very complicated working cycle for a console-oriented person; in Unix shells (probably you should once compare TCC to zsh ;-) reloading can be accomplished from the command line with just a keystroke.
- May
- 3,515
- 5
Your example does not indicate a need to be able to reconfigure TCMD/TCC. If the environment variable COLORDIR is defined, it overrides the ColorDir directive, and it can be changed with a simple SET command, without a lot of overhead. Furthermore, you can change the ColorDir directive itself which is in effect by the command OPTION //ColorDir=... from the command line, and it would NOT update tcmd.ini. If you, like myself, is keyboard oriented, that's a much simpler operation than going into the OPTION dialog (which can still me modified just from the keyboard).
There are, of course, some directives whose value cannot be changed once they were set from the initialization file. To run an instance of TCMD or TCC with temporarily modified values you can save the edited initialization data as a separate file, and specify the new file as a parameter in the command which starts the new instance. BTW, none of the original Unix shells (Bourne, C, Korn) have the reinitialization feature, IIRC.
There are, of course, some directives whose value cannot be changed once they were set from the initialization file. To run an instance of TCMD or TCC with temporarily modified values you can save the edited initialization data as a separate file, and specify the new file as a parameter in the command which starts the new instance. BTW, none of the original Unix shells (Bourne, C, Korn) have the reinitialization feature, IIRC.
- Jun
- 223
- 0
@Steve
1/ The ColorDir option was - as I stated above - just an example.
However, I'd rather like (from a "single-point-of-change" perspective) to use a persistent configuration file (with the option to re-source) it, in favor of a - somewhat volatile - environment variable (or OPTION //ColorDir= statement for that matter).
2/ No? What about "source .bashrc", or "re-read-init-file" (readline)? ;-)
I think the point here is that most Unix shells use a single configuration file (apart from the fact, that they differentiate login/non-login/interactive shells, and the respective initialization files), where TCC makes use of a two file approach (tcstart.btm and tcmd.ini, don't nail me on the names) with two completely different syntaxes. While I can re-execute my tcstart.btm, I cannot do this with tcmd.ini (at least not that I know of - and Rex's answer seems to confirm this...).
@Rex
1) Can I use an empty tcmd.ini (or none for that matter) and only "OPTION //<option>=<value>" commands in tcstart.cmd (providing I NEVER use the OPTION GUI)?
2) Can all tcmd.ini options be set in this fashion, or do I have to expect "side effects"?
1/ The ColorDir option was - as I stated above - just an example.
However, I'd rather like (from a "single-point-of-change" perspective) to use a persistent configuration file (with the option to re-source) it, in favor of a - somewhat volatile - environment variable (or OPTION //ColorDir= statement for that matter).
2/ No? What about "source .bashrc", or "re-read-init-file" (readline)? ;-)
I think the point here is that most Unix shells use a single configuration file (apart from the fact, that they differentiate login/non-login/interactive shells, and the respective initialization files), where TCC makes use of a two file approach (tcstart.btm and tcmd.ini, don't nail me on the names) with two completely different syntaxes. While I can re-execute my tcstart.btm, I cannot do this with tcmd.ini (at least not that I know of - and Rex's answer seems to confirm this...).
@Rex
1) Can I use an empty tcmd.ini (or none for that matter) and only "OPTION //<option>=<value>" commands in tcstart.cmd (providing I NEVER use the OPTION GUI)?
2) Can all tcmd.ini options be set in this fashion, or do I have to expect "side effects"?
- May
- 3,515
- 5
On "Steve 1": Tastes vary. I would rather not modify a file when I want a single option to be different for a short time - I might forget to restore the file, and other things would misbehave. Your approach is fine for a configuration that is used exclusively for interactive operation only, but think what it could do to batch programs running unattended!
On "Steve 2": I explicitly stated Unix and named its 3 decades-old command processors, not any of their imitations - Linux, BSD, bash, zsh, etc. And the command "source" is only usable in some of them, not all! In ksh you can use the period (.) instead. Furthermore, IIRC, just rerunning the configuration file will not REMOVE entries which had already been set, and are not referenced in the current configuration file. For example, if you defined an alias, either from the command line or from another command procedure file (shell script in *nix, batch file in PC) it will remain. AFAIK you cannot restore all defaults! As to TCC's two-file approach, different syntax is used in .INI files to overcome the limitations of batch file syntax - it would require very torturous methods to set some of the directives in commands.
For your questions directed to Rex, there are many directives that can only be processed when a new instance of TCC starts, from the .INI file; modifying of the .INI file by any technique, including the OPTION dialog, will take effect only when a new instance is started. You can continue using the old values in the TCC instance which was used to modify them.
On "Steve 2": I explicitly stated Unix and named its 3 decades-old command processors, not any of their imitations - Linux, BSD, bash, zsh, etc. And the command "source" is only usable in some of them, not all! In ksh you can use the period (.) instead. Furthermore, IIRC, just rerunning the configuration file will not REMOVE entries which had already been set, and are not referenced in the current configuration file. For example, if you defined an alias, either from the command line or from another command procedure file (shell script in *nix, batch file in PC) it will remain. AFAIK you cannot restore all defaults! As to TCC's two-file approach, different syntax is used in .INI files to overcome the limitations of batch file syntax - it would require very torturous methods to set some of the directives in commands.
For your questions directed to Rex, there are many directives that can only be processed when a new instance of TCC starts, from the .INI file; modifying of the .INI file by any technique, including the OPTION dialog, will take effect only when a new instance is started. You can continue using the old values in the TCC instance which was used to modify them.
- Jun
- 223
- 0
@Steve
1/ But that's my intention; I want persistent changes (hence the word "persistent" in my post) to become active w/o me having to quit TCC. For any non-persistent changes I already use the apropriate methods.
2/ Come on, already good old Unix sh knows the . (source) syntax.
Also, I don't want to restore "all the defaults", I just want a change that I make to become active w/o the need to have to quit TCC. I'm aware that some settings might put me (non-persistently ;-) in trouble, but that'd be my problem then.
3/ Can you give me a list of these options?
1/ But that's my intention; I want persistent changes (hence the word "persistent" in my post) to become active w/o me having to quit TCC. For any non-persistent changes I already use the apropriate methods.
2/ Come on, already good old Unix sh knows the . (source) syntax.
Also, I don't want to restore "all the defaults", I just want a change that I make to become active w/o the need to have to quit TCC. I'm aware that some settings might put me (non-persistently ;-) in trouble, but that'd be my problem then.
3/ Can you give me a list of these options?
- May
- 3,515
- 5
I had to search hard to find the word "persistent" in your post (actually a previous reply), and it qualified "configuration file" - not its contents. You can create an alias to update the configuration file used by the current TCC session ("%@iniwrite[%_ininame,section,directive,value]") and also modify using and make it effective for the current instance by option //directive=value in one command.
ksh used to be my favorite on real Unix - I even discussed some of its fine points with Dr. Korn by phone when I was on contract of a (then) BTL facility. It does not know "source", though it has an equivalent. IIRC you can create an alias translating source to a period to make csh/sh scripts more compatible.
Ah, that's different. You could TRY this logic:
for each line of file (
if not in [4NT] section, ignore
trim line, delete trailing comments if any
option //line)
Sorry, no. Some which were not dynamically modifiable in earlier versions of the JPsoft command processor are now modifiable. Surprisingly for those of us who don't want to give up the keyboard for the mouse (or have cats at home to eat them) and who think you must be sufficiently technically oriented to be interested in using TCC to be able to deal with the difference between directive. command, alias, environment variable, ... in their appropriate manner, Rex has many much less sophisticated customers, thus the OPTION dialog. Through version 8 the list of directives and their ranges were included in the documentation. They are no longer because Rex reported them to be a support nightmare - most support requests related to them. OPTION will not allow you to set most of them to invalid values, though you can still refer to a non-existent drive etc.
Charles Dye
Super Moderator
- May
- 5,388
- 166
Staff member
You can't configure (or check) the key mapping directives after TCC starts.
There may be other directives you can't configure dynamically; I just happen to know about the key-mapping ones.
rconn
Administrator
- May
- 13,683
- 257
Staff member
Take Command has one initialization file. TCSTART is a startup script; it has nothing to do with initialization.
You could, but it would be undocumented, unsupported, and highly unrecommended. (And pretty slow, too.) And you'd have to keep erasing TCMD.INI, because TCC will keep trying to update it when you change certain options (and sometimes on exit, depending on the .INI values).
No, and definitely yes. Assuming you even knew what all of the TCMD.INI options are (and you don't!).