Environment variable in tcmd.ini
- Thread starter element
- Start date
rconn
Administrator
- May
- 13,334
- 218
Staff member
WAD -- variables are not expanded during .INI processing. For most .INI
directives it's irrelevant, and for the rest TCMD doesn't have any way of
knowing whether to expand variables when loading TCMD.INI or when executing
commands.
Rex Conn
JP Software
Well, it's relevant to cross-platform setup of user's logs, history files, start dir, etc. "Has no way of knowing" - isn't %VAR or %VAR% enough of a clue that we're dealing with an env. var? tcmd.ini could also have an explicit flag: "Expand env. variables: yes/no".
rconn
Administrator
- May
- 13,334
- 218
Staff member
The problem isn't recognizing that there's a variable, the problem is that
(1) TCC can't tell if you want it expanded now or later, and (2) at the time
the TCMD.INI file is parsed, the TCC parser isn't yet capable of doing
expansion (because there are a lot of .INI options that define subsequent
expansion parameters).
Rex Conn
JP Software
- May
- 3,515
- 5
| ---Quote (Originally by rconn)---
|| For most .INI directives it's irrelevant, and for the rest TCMD
|| doesn't have any way of knowing whether to expand variables when
|| loading TCMD.INI or when executing commands.
| ---End Quote---
| Well, it's relevant to cross-platform setup of user's logs, history
| files, start dir, etc. "Has no way of knowing" - isn't %VAR or %VAR%
| enough of a clue that we're dealing with an env. var? tcmd.ini could
| also have an explicit flag: "Expand env. variables: yes/no".
The issue of using environment variables to specify the values of .INI
directives has come up many times in the past. IMHO the implementation
should be to expand them as processed, without any explicit flag, under all
circumstances. If the user wants it to be postponed until command execution,
the OPTION command can be used either in TCSTART, or at any time before
executing the command utilizing the value of the directive of interest. The
only case in which this approach would fail is for a directive that cannot
be modified by the OPTION command, but I find such directives to be very
unlikely candidates for being set by variables, anyway.
--
Steve
|| For most .INI directives it's irrelevant, and for the rest TCMD
|| doesn't have any way of knowing whether to expand variables when
|| loading TCMD.INI or when executing commands.
| ---End Quote---
| Well, it's relevant to cross-platform setup of user's logs, history
| files, start dir, etc. "Has no way of knowing" - isn't %VAR or %VAR%
| enough of a clue that we're dealing with an env. var? tcmd.ini could
| also have an explicit flag: "Expand env. variables: yes/no".
The issue of using environment variables to specify the values of .INI
directives has come up many times in the past. IMHO the implementation
should be to expand them as processed, without any explicit flag, under all
circumstances. If the user wants it to be postponed until command execution,
the OPTION command can be used either in TCSTART, or at any time before
executing the command utilizing the value of the directive of interest. The
only case in which this approach would fail is for a directive that cannot
be modified by the OPTION command, but I find such directives to be very
unlikely candidates for being set by variables, anyway.
--
Steve
- May
- 3,515
- 5
| Seems like TCC doesn't like environment variables in tcmd.ini. I've
| got an env. var called HOME defined as "C:\home" and I'm trying to
| use %HOME as the startup dir in tcmd.ini. I'm on Win7 64, TCC 11.
I have strugled with this issue myself, not only in Windows, but also in
many other operating systems, and - just like you - found relief in using an
identical hierarchy on each system, and defining a fixed set of symbols to
have values dependent on the hardware instance. For using 4DOS through TCC
the basic solution is to explicitly specify the start directory, and usually
the name of the .INI file itself, in either the shortcut (.LNK) file (which
can be built with the SHORTCUT command on each system to which you migrate)
or in the START command which is used to start TCC. If you need to use the
RUN command, you may want it to start an instance of TCC just to allow use
of the START command with all required parameters. The other scenario in
which the issue comes up, and is much harder to handle, is when you use a
portable device to run from, which might not have the same drive letter even
on the same system each time you use it. AUTORUN is your friend - and you
again may wish to use the "two step" method.
--
HTH, Steve
| got an env. var called HOME defined as "C:\home" and I'm trying to
| use %HOME as the startup dir in tcmd.ini. I'm on Win7 64, TCC 11.
I have strugled with this issue myself, not only in Windows, but also in
many other operating systems, and - just like you - found relief in using an
identical hierarchy on each system, and defining a fixed set of symbols to
have values dependent on the hardware instance. For using 4DOS through TCC
the basic solution is to explicitly specify the start directory, and usually
the name of the .INI file itself, in either the shortcut (.LNK) file (which
can be built with the SHORTCUT command on each system to which you migrate)
or in the START command which is used to start TCC. If you need to use the
RUN command, you may want it to start an instance of TCC just to allow use
of the START command with all required parameters. The other scenario in
which the issue comes up, and is much harder to handle, is when you use a
portable device to run from, which might not have the same drive letter even
on the same system each time you use it. AUTORUN is your friend - and you
again may wish to use the "two step" method.
--
HTH, Steve
Charles Dye
Super Moderator
- May
- 5,220
- 147
Staff member
I think that people are just wanting environment variables, not internal variables or functions or pseudovars or whatever. If you could expand those, replacing doubled percents signs with single ones, then users could use e.g. %USERPROFILE% if they want it expanded during .INI processing, or %%USERPROFILE%% if they want it expanded later.
The real trick might be deciding which directives should support environment-variable expansion. I think it might not be appropriate in all lines....
- May
- 13,397
- 190
On Fri, 02 Apr 2010 09:12:16 -0400, rconn <> wrote:
|The problem isn't recognizing that there's a variable, the problem is that
|(1) TCC can't tell if you want it expanded now or later, and (2) at the time
|the TCMD.INI file is parsed, the TCC parser isn't yet capable of doing
|expansion (because there are a lot of .INI options that define subsequent
|expansion parameters).
Except for TC button specifications, I can't think of a situation where I'd want
to use a variable name in the INI file and not have it expanded when the INI
file is read (wanting, rather, that it be expanded at some later time). Can you
give such an example?
Almost all the directives take values of "Yes". "No", a key name, or a number. I
doubt anyone is suggesting that environment variables be honored there. Only a
handful (or two) directives would seem appropriate for variable processing ...
Editor, log file names, start-up file locations, and perhaps MailAddress,
Comspec, StartDirectory (any others?).
--
- Vince
|The problem isn't recognizing that there's a variable, the problem is that
|(1) TCC can't tell if you want it expanded now or later, and (2) at the time
|the TCMD.INI file is parsed, the TCC parser isn't yet capable of doing
|expansion (because there are a lot of .INI options that define subsequent
|expansion parameters).
Except for TC button specifications, I can't think of a situation where I'd want
to use a variable name in the INI file and not have it expanded when the INI
file is read (wanting, rather, that it be expanded at some later time). Can you
give such an example?
Almost all the directives take values of "Yes". "No", a key name, or a number. I
doubt anyone is suggesting that environment variables be honored there. Only a
handful (or two) directives would seem appropriate for variable processing ...
Editor, log file names, start-up file locations, and perhaps MailAddress,
Comspec, StartDirectory (any others?).
--
- Vince
- May
- 3,515
- 5
| ---Quote (Originally by rconn)---
|| The problem isn't recognizing that there's a variable, the problem
|| is that (1) TCC can't tell if you want it expanded now or later, and
|| (2) at the time the TCMD.INI file is parsed, the TCC parser isn't
|| yet capable of doing expansion (because there are a lot of .INI
|| options that define subsequent expansion parameters).
| ---End Quote---
| I think that people are just wanting environment variables, not
| internal variables or functions or pseudovars or whatever. If you
| could expand those, replacing doubled percents signs with single
| ones, then users could use e.g. %USERPROFILE% if they want it
| expanded during .INI processing, or %%USERPROFILE%% if they want it
| expanded later.
I concur that only the environment variables defined before TCC is invoked
are relevant here. Personally I'd even be willing to give up the "delayed
expansion" Charles suggests, they can be done in TCSTART, etc. What would be
also extremely useful is accepting "relative path", e.g.
logname=..\log\jpcmnd.log, for all directives specifying the path of
relevant items, to be interpreted relative to the location of the .INI file
currently processed.
--
Steve
|| The problem isn't recognizing that there's a variable, the problem
|| is that (1) TCC can't tell if you want it expanded now or later, and
|| (2) at the time the TCMD.INI file is parsed, the TCC parser isn't
|| yet capable of doing expansion (because there are a lot of .INI
|| options that define subsequent expansion parameters).
| ---End Quote---
| I think that people are just wanting environment variables, not
| internal variables or functions or pseudovars or whatever. If you
| could expand those, replacing doubled percents signs with single
| ones, then users could use e.g. %USERPROFILE% if they want it
| expanded during .INI processing, or %%USERPROFILE%% if they want it
| expanded later.
I concur that only the environment variables defined before TCC is invoked
are relevant here. Personally I'd even be willing to give up the "delayed
expansion" Charles suggests, they can be done in TCSTART, etc. What would be
also extremely useful is accepting "relative path", e.g.
logname=..\log\jpcmnd.log, for all directives specifying the path of
relevant items, to be interpreted relative to the location of the .INI file
currently processed.
--
Steve
rconn
Administrator
- May
- 13,334
- 218
Staff member
Which would break existing .INI files (particularly toolbar definitions).
Nobody has come up with a use for this that can't already be done in
TCSTART.
To recapitulate (for the nth time in n years), this *cannot* be done without
creating a preparser for the .INI files, combined with a new parser for the
variable expansion (because the variable expansion parser DOES NOT EXIST at
the time the .INI files are being parsed).
All in all, a LOT of work for me, while providing no discernible benefit for
the users.
Rex Conn
JP Software
If you had to explain this n times in n years, I'd say there's a very discernible interest among the users... ;)
rconn
Administrator
- May
- 13,334
- 218
Staff member
You might think that, but n-2 of those requests have come (repeatedly) from
one user! :-)
"Interest" doesn't in this case equate to "necessary" (given the existing
supported solution of the TCSTART file), nor unfortunately does it equate to
"feasible".
Rex Conn
JP Software
- Nov
- 250
- 2
I've multibooted since the early 1990s. The various 4DOS/4OS2/4NT/TCMD files (.BTM, .ALS, .ENV), are built from a central file, which runs under EXTPROC and a rexx script. Of course, one can include a line directly after the extproc one, like "regina.exe weave.rex %0" and "goto :eof".
It's pretty much as in a nested language, where !set creates a variable, !inc and !exe are GOSUB , !end or label is RETURN, and !src and !lbl are labels. It is read into memory and run from there.
You then only have to edit the program sets to allow the program to install in a new computer.
It's pretty much as in a nested language, where !set creates a variable, !inc and !exe are GOSUB , !end or label is RETURN, and !src and !lbl are labels. It is read into memory and run from there.
You then only have to edit the program sets to allow the program to install in a new computer.
Code:
extproc weave.rex
!src
!set ypath #g:\save\newin\jpsoft#
!new #ypath#\4start.btm
!put #@echo off##
!inc startnt
!new #ypath#\tcstart.btm
!put #@echo off##
!inc starttc
!new #ypath#\alias.4nt
!inc aliases
!inc alias4nt
!new #ypath#\alias.tc
!inc aliases
!inc aliastc
!new #ypath#\environ.4nt
!inc environ4nt
!inc environs
!new #ypath#\environ.tc
!inc environtc
!inc environs
!end
!topic 4start
!src startnt
!put #alias /r #ypath#\alias.4nt##
!put #set /r #ypath#\environ.4nt##
!lbl starttc
!put #alias /r #ypath#\alias.tc##
!put #set /r #ypath#\environ.tc##
!end
Aliases with a semicolon represent cdd directory.
!topic Aliases
!src aliases
dl:=m:\download
cdata:=h:\save\cdata
usr:=g:\users\wendy
drives=echo %_drives
!lbl alias4nt
!lbl aliastc
!end
secon32 = Scriptease (CEnvi).
!topic Environment
!src environs
.rex=regina.exe
.cmm=secon32.exe
!lbl environ4nt
!lbl environtc
!end
!end- May
- 3,515
- 5
Vince wrote:
| Almost all the directives take values of "Yes". "No", a key name, or
| a number. I doubt anyone is suggesting that environment variables be
| honored there. Only a handful (or two) directives would seem
| appropriate for variable processing ... Editor, log file names,
| start-up file locations, and perhaps MailAddress, Comspec,
| StartDirectory (any others?).
I concur. Keymapping is one area where a user may want to use different
keymappings for a laptop (or other small keyboard) and for a full keyboard,
or in some instances, for English vs. foreign keyboard. That's when more
dynamic assignment is very useful. One alternative is the use of an INCLUDE
file, containing the key mapping directives for the specific machine. But
there is no information on what the drive letter is when one runs TCC off a
portable drive!
--
Steve
| Almost all the directives take values of "Yes". "No", a key name, or
| a number. I doubt anyone is suggesting that environment variables be
| honored there. Only a handful (or two) directives would seem
| appropriate for variable processing ... Editor, log file names,
| start-up file locations, and perhaps MailAddress, Comspec,
| StartDirectory (any others?).
I concur. Keymapping is one area where a user may want to use different
keymappings for a laptop (or other small keyboard) and for a full keyboard,
or in some instances, for English vs. foreign keyboard. That's when more
dynamic assignment is very useful. One alternative is the use of an INCLUDE
file, containing the key mapping directives for the specific machine. But
there is no information on what the drive letter is when one runs TCC off a
portable drive!
--
Steve