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

WAD New envars for @LINES are not hidden

Discussion in 'Support' started by djspits, Apr 4, 2013.

  1. djspits

    Joined:
    Apr 13, 2010
    Messages:
    189
    Likes Received:
    2
    They are visible in the normal environment.
    Cheers, DJ.
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    WAD - they're supposed to be. They're not internal variables.
     
  3. djspits

    Joined:
    Apr 13, 2010
    Messages:
    189
    Likes Received:
    2
    I'm curious why you would want to design it that way?
    Me, I'm comparing them with the likes of e.g. _copy_files
     
  4. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    Because they're variables generated by a variable function, not a command. The variable parsing nesting would get ugly.

    Why do you care?
     
  5. djspits

    Joined:
    Apr 13, 2010
    Messages:
    189
    Likes Received:
    2
    'cause you've just invented a new way for envars to appear. And I have to tame them.:)
    dj
     
  6. Howard Goldstein

    Joined:
    Jun 1, 2008
    Messages:
    111
    Likes Received:
    1
    I think that one of the things that's confusing here is that some of these new variable names begin with a _ character. Even though there has never been any prohibition against beginning an environment variable name with a _, we, or at least I tend to automatically assume that any variable beginning with _ is a TCC system variable. I had to read the help several times before it registered that these were ENVIRONMENT variables.

    Another point of possible confusion is that some of these new variables begin with _ and others don't. For example we now have two new variables associated with @SELECT, SELECT_LINE and _SELECT_KEY. Is there any kind of rule of thumb that we can use to help us remember or understand which variables begin with an underscore and which do not?

    --
    Howard
     
  7. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    Actually the variables are SELECT_LINE and _SELECT_KEY. What is confusing is that for the first time an environment variable (_SELECT_KEY) has been defined with a leading underscore. In all previous version the leading underscore was reserved for internal variables. Of course, there is little practical difference - only the IF DEFINED test behaves differently. One could always define one's own environment variable (ev) with the same name as an internal variable (iv), and once done, only the value of the ev was accessible (until UNSET was used to undefine the ev, making the value of the iv accessible again).

    The debugger allows viewing / monitoring iv-s, not just ev-s.

    Rex: @execarray reports a count in _execarray which is an iv - why is that one easier for the parser than using iv-s for @SELECT and @LINES reports?
     
  8. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    @EXECARRAY is executed in a separate nested invocation of the parser (and written to a temp file).
     
  9. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    Thanks for the explanation, Rex.
     

Share This Page