1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Environment variable in tcmd.ini

Discussion in 'Support' started by element, Apr 2, 2010.

  1. element

    Joined:
    Jun 1, 2008
    Messages:
    30
    Likes Received:
    0
    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.
     
  2. dim

    dim Dimitry Andric

    Joined:
    May 31, 2008
    Messages:
    203
    Likes Received:
    0
    On 2010-04-02 08:38, element wrote:

    Nope, unfortunately it does not support that, it never has. This makes tcmd.ini files unportable across different user accounts and systems...
     
  3. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,863
    Likes Received:
    83
    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
     
  4. element

    Joined:
    Jun 1, 2008
    Messages:
    30
    Likes Received:
    0
    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".
     
  5. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,863
    Likes Received:
    83
    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
     
  6. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | ---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
     
  7. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | 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
     
  8. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    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....
     
  9. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,962
    Likes Received:
    30
    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
     
  10. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | ---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
     
  11. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,863
    Likes Received:
    83
    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
     
  12. element

    Joined:
    Jun 1, 2008
    Messages:
    30
    Likes Received:
    0
    If you had to explain this n times in n years, I'd say there's a very discernible interest among the users... ;)
     
  13. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,863
    Likes Received:
    83
    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
     
  14. w_krieger

    Joined:
    Nov 2, 2008
    Messages:
    176
    Likes Received:
    0
    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.


    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
    
    
     
  15. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    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
     

Share This Page