> On Jul 29, 2019, at 3:30 PM, Stephane Chazelas <stephane.chaze...@gmail.com>
> wrote:
>
> 2019-07-29 22:25:29 +0100, Stephane Chazelas:
>> 2019-07-29 21:33:50 +0100, Stephane Chazelas:
>> [...]
>>> BTW, what's the point of 2.10.2 7a? It seems 7b already says
>>> what 7a says (if the TOKEN doesn't contain a =, then rule 1
>>> applies). The distinction seems to be caused by the distinction
>>> between cmd_name vs cmd_word grammar rules which seems to be
>>> about keywords not being recognised after redirections or
>>> assignments, but I can't see how 7a/7b help there.
>> [...]
>>
>> It seems it was broken in the 2016 edition by the resolution of
>> http://austingroupbugs.net/view.php?id=839
> [...]
>
>
> I see it (and several other issues) was already raised in
> http://austingroupbugs.net/view.php?id=1100
> which was rejected.
>
> The grammar in the suggested resolution there makes a lot more
> sense to me than the current one but that may be down to me
> missing some background on yacc parsing and misunderstanding how
> it works.
>
> Since 1100 was rejected, shouldn't the other issues it was meant
> to factorize (which doesn't include this one though) and were
> closed as duplicate reopened?
>
> --
> Stephane
Hi Stephane,
No. The reasons why bugid:1100 was rejected are clearly detailed in
bugnote:4038. None of those issues have been addressed in the more than 14
months since that bug report was rejected. There is no reason to believe that
if we reopened all of the bugs that Mark said were replaced by bugid:1100 that
we would not just be wasting our time and rejecting each one of them with a
duplicate of bugnote:4038 as the reason for rejection.
Please do not tell us to go back and redo a lot of work we did over a year ago.
If you think you understand the problem(s) better than Mark did, please file a
new bug (or a few new bugs) that clearly states the problem that each is
addressing, gives examples of shell productions that are incorrectly handled by
the current grammar, explains how your changes fix the problem (without
creating new problems), and defines all new terms used by your changes. All of
this is detailed in bugnote:4038.
Sincerely,
Don
