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.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.
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.2/ Come on, already good old Unix sh knows the . (source) syntax.
Ah, that's different. You could TRY this logic: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.
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.3/ Can you give me a list of these options?
Take Command has one initialization file. TCSTART is a startup script; it has nothing to do with initialization.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.
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).@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)?
No, and definitely yes. Assuming you even knew what all of the TCMD.INI options are (and you don't!).2) Can all tcmd.ini options be set in this fashion, or do I have to expect "side effects"?