Question RE: SourceForge bug id 104052 - case study.

["Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>]

>
> Case 2.
>
> bor@itsrm2% print $foo[\]]
> ]
> bor@itsrm2% print ${foo[\]]}
> zsh: bad substitution
>
...
>
> Case 2 comes from the fact, that paramsubst() and getindex() treat
> both quoted
> and unquoted brackets the same. The reason is (as I suspect) parameter
> substitution in double-quotes - "$foo[bar]". When it is parsed by
> dquote_parse(), it adds just plain ']' and not Outbrack; so, when it finally
> reaches paramsubst() it may encounter both values. When inside of
> parens, Zsh
> just warns about missing closing one (because it finds end of
> substitution too
> early).
>
...
>
> Case 2 - lexer should return different token for "]" as for \],
> e.g. Qoutbrack
> like Qstring. And, of course, all uses of ']'/Outbrack should be checked ...
> but note, that in this case
>
> $foo[\]]
>
> will be valid, but
>
> "$foo[\]]"
>
> not. By definition, you cannot quote inside of double quotes. Even
>
> $foo["]"]
>
> will be invalid in this case (a bit unexpected), unless code can be smart
> enough to notice, that initial Inbrack was not quoted.
>


This may work if we allow backslash to quote `]' inside of doublequotes.
Because POSIX explcitly forbids it, it should be turned off at least in sh
mode; so something like new option SH_STRICT_QUOTING is needed (or, probably,
even POSIX_STRICT_QUOTING would be better name). That will make $foo[\]] and
"$foo[\]]" both work and produce the same result.

Neither sh nor ksh have this problem, as they do not have associated arrays; I
could not compile new ksh so I do not know how it behaves.

If there is no much con, I'll give it a try.

-andrej