WAD New envars for @LINES are not hidden

[djspits]

They are visible in the normal environment.
Cheers, DJ.

 

[rconn]

WAD - they're supposed to be. They're not internal variables.

 

[djspits]

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

 

[rconn]

Because they're variables generated by a variable function, not a command. The variable parsing nesting would get ugly.

Why do you care?

 

[djspits]

'cause you've just invented a new way for envars to appear. And I have to tame them.:)
dj

 

[Howard Goldstein]

Because they're variables generated by a variable function, not a command. The variable parsing nesting would get ugly.

Why do you care?

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

 

[Steve Fabian]

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?

 

[rconn]

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?

@EXECARRAY is executed in a separate nested invocation of the parser (and written to a temp file).

 

[Steve Fabian]

Thanks for the explanation, Rex.