A NOTE has been added to this issue. ====================================================================== https://www.austingroupbugs.net/view.php?id=1454 ====================================================================== Reported By: geoffclare Assigned To: ====================================================================== Project: 1003.1(2016/18)/Issue7+TC2 Issue ID: 1454 Category: Shell and Utilities Type: Error Severity: Comment Priority: normal Status: New Name: Geoff Clare Organization: The Open Group User Reference: Section: 2.9.4.3 Page Number: 2372 Line Number: 75780 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2021-02-16 16:29 UTC Last Modified: 2021-02-18 10:32 UTC ====================================================================== Summary: Conflict between "case" description and grammar ======================================================================
---------------------------------------------------------------------- (0005246) kre (reporter) - 2021-02-18 10:32 https://www.austingroupbugs.net/view.php?id=1454#c5246 ---------------------------------------------------------------------- Re https://www.austingroupbugs.net/view.php?id=1454#c5245 That raises an additional problem, as (not concerning the case productions here) that isn't the way things actually work. "convert the token identifier type of the TOKEN to a token identifier acceptable at that point in the grammar." isn't what (normally) happens. If it were the command do my work would run the "do" command, as "do" (the reserved word) is not acceptable at that point in tne grammar, so the TOKEN "do" should have been (according to that text) turned into a WORD rather tha nthe keywoprd "do". There isn't a shell around that behaves like that, it is in the command line position, "do" matches the spelling of the reserved word, Rule 1 applies, the reserved word is generated, despite not being "acceptable at that point in the grammar":. Once we have an explanation for why this analysis isn't right, or a fix for that text in 2.10.1 we can revisit how to handle the recognition of "ecac" in that peculiar case statement with no patterns. Issue History Date Modified Username Field Change ====================================================================== 2021-02-16 16:29 geoffclare New Issue 2021-02-16 16:29 geoffclare Name => Geoff Clare 2021-02-16 16:29 geoffclare Organization => The Open Group 2021-02-16 16:29 geoffclare Section => 2.9.4.3 2021-02-16 16:29 geoffclare Page Number => 2372 2021-02-16 16:29 geoffclare Line Number => 75780 2021-02-16 16:29 geoffclare Interp Status => --- 2021-02-16 20:44 kre Note Added: 0005241 2021-02-16 20:55 kre Note Added: 0005242 2021-02-16 21:02 kre Note Edited: 0005242 2021-02-17 10:07 geoffclare Note Added: 0005243 2021-02-17 13:18 kre Note Added: 0005244 2021-02-17 14:26 geoffclare Note Added: 0005245 2021-02-18 10:32 kre Note Added: 0005246 ======================================================================
