rconn wrote:
| Steve Fábián wrote:
| ---Quote---
|| The OP's issue here was that array variables cannot have leading
|| spaces, while environment variables can. To me that's a
|| compatibility issue. If I need the possibility of leading space in a
|| variable in an application, I cannot use an array variable for that
|| case, even if that's the convenient one. I have to revert to
|| pseudoarrays of environment variables. Since arrays are new in V10,
|| and the impossibility of an array element value to have leading
|| spaces is not documented, changing the behavior of SET to be
|| independent of the type of variable to be set would create more
|| compatibility, not less.
| ---End Quote---
| The OP didn't *want* leading spaces, he just noticed a difference.
|
| The only compatibility issue would be if you were trying to use array
| variables in a CMD batch file, which isn't possible.
You do not consider (as yet undocumented) different behavior of SET
depending on the type of variable it operates on a compatibility issue?
Consider the following batch program:
set %1=%@line[%2,0]
echo %1="%[%1]"
If the value to which variable %1 is set depends on its type (array element
vs. environment) if the first line of file %2 has leading white space I
think we have a compatibility issue. Not compatiblity with other programs
(e.g. CMD), but within TCC. The issue exists with SET, INKEY and INPUT, none
of which will set an array element to have leading space, and all of which
can set at environment variable to have leading space.
|
| IMO this is an imaginary issue, not a real one. Since you didn't
| notice any problem for 8 months (and not until somebody else
| mentioned it),
| it's unlikely that it's a critical issue for you. (Particularly since
| there are several well known and documented workarounds if you were
| actually deranged enough to want to do this!)
I need to confess that while I was one of the requestors of array variables,
I had not started using them. I did some testing early in the beta phase,
but I had trouble installing many of the later builds of V10 (due to MS
software behaving differently than documented, and which you solved), and
had been busy with other tasks, so I kept using V9 for produciton work when
arrays would have been much more convenient, but I already had working
solutions without them. Vince's discovery makes it less likely that now,
when I need to modify my batch programs I would rebuild them with arrays.
What methods are available to set an array element to have one or more
leading space characters?
|
| ---Quote---
|| Why is a leading space character a delimiter, but an embedded space
|| character data?
| ---End Quote---
| Embedded spaces are delimiters too.
If so, why does
set a[0]=z z ``
work (the value, quoted, is "z z "), but
set a[0]=`` z z ``
result in the same value?
| ---Quote---
|| Furthermore, to make space characters delimiters in a command line
|| does not require them to be made delimiters in data. The biggest
|| problem (introduced by Microsoft 30 years ago when they defined the
|| syntax for COMMAND.COM 1.0) is the lack of clear disambiguation
|| between data and command.
| ---End Quote---
| Not sure what your point is here -- are you arguing against
| compatibility with CMD?
My first sentence relates to interpreting information. All programs contain
both commands and data. Most programming languages, whether they are
designed exclusively to be interpreted only, or designed to be compiled only
for future execution, or both, observe a dichotomy: some parts of the
program are commands on what to do, and other parts of the program are data
to be processed. Once the parser determined that some sequence of characters
is a datum, e.g. whatever follows the equal sign = in a SET command
(including command line continuations, but excluding such datum terminations
as unescaped symbols for redirection, piping, command separation, etc.)
delimiters used to separate command line tokens ought not to be used within
the datum (string).
My second sentence blames MS on muddling the clear dichotomy, allowing such
constructs in TCC as
for %x in (alias function set) for %z in (*.%@left[3,%x]) %x /r %z
which is a convenient, but unnecessary shorthand for writing three separate
commands. It may reduce the size of a batch file, but increase the time of
its execution (unless you still have a floppy disk from which to run it).
--
Steve