| Once you say "SETARRAY n[5]", the individual elements are "defined".
Compare with environment variables. All possible variable names are
always declared IMPLICITLY, and their values accessible without ever
initializing them. If not previously initialized, the value as a string is
the empty string, and as a numeric value it is zero. For example, the
following is perfectly operable code:
UNSET Z
SET /A Z+=1
In the same manner your command above makes %n[0] ... %n[4] accessible,
and %n[5] still inaccessible. You need to use @execarray, @filearray, or SET
to actually initialize the individual array elements just as if they were
independent environment variables.
When you initialize an array's elements using the @filearray function,
its value tells you how many elements you actually initialized.
Unfortunately @execarray does not provide that information, nor does it load
the uninitialized elements with the equivalent of **EOC** as @CLIP[] reports
or with **EOF** as @fileread[] does. In fact you have to know the output
format of the command A PRIORI to locate the end of data. This is why I
requested a change in @execarray.
When the array is initialized using @filearray or @execarray, some
elements may be initialized to empty strings, corresponding to blank lines.
When you process a file using "for %x in (@file) ..." or its DO equivalent,
the test "if defined x" is the simple test for a blank line. I was looking
for a similarly simple test when the file (or command output) is put into an
array. Your test "%n[%i]" NE "" is logically equivalent to what I used to do
for environment variables before DEFINED was available, %@len[%n[%i]] GT 0,
but I am sure both are slower than DEFINED n[%i] would be, though I am not
sure whether your test or mine is faster, but DEFINED is definitely simpler
to understand.
--
Steve
