Re: [PATCH] Fix blocking read timeouts at a small probability

On Mon, Feb 15, 2021 at 09:41:29AM -0500, Chet Ramey wrote: > Just for testing, not for any real use case. > > > He also provided me with his new test case > > to see the interaction with SIGCHLD. The failure of this test case > > seems to have also involved SIGCHLD in the previous devel Bash. Now

Re: syntax error while parsing a case command within `$(...)'

On Feb 16 2021, Koichi Murase wrote: > Because the ending keywords---}, fi, done, and esac---are allowed to > be chained, which I think is undocumented though. See 2.4 Reserved Words. This recognition shall only occur when none of the characters is quoted and when the word is used as:

Re: syntax error while parsing a case command within `$(...)'

2021年2月16日(火) 16:28 Andreas Schwab : > See 2.4 Reserved Words. > > This recognition shall only occur when none of the characters is > quoted and when the word is used as: I think that section just describes the necessary condition that the word is recognized as the reserved keyword: "This

Re: syntax error while parsing a case command within `$(...)'

16 Şubat 2021 Salı tarihinde Koichi Murase yazdı: > OK, now I understood this behavior is > actually required by the POSIX standard. Can we find any textual > explanation on this rule? Or maybe this behavior is intuitive enough > for those who understand the shell grammar so that they don't see t

Re: syntax error while parsing a case command within `$(...)'

On 16/02/2021 10:19 am, Koichi Murase wrote: 2021年2月16日(火) 16:28 Andreas Schwab : See 2.4 Reserved Words. This recognition shall only occur when none of the characters is quoted and when the word is used as: I think that section just describes the necessary condition that the word i

Re: syntax error while parsing a case command within `$(...)'

2021年2月16日(火) 19:29 Chris Elvidge : > > I think that section just describes the necessary condition that the > > word is recognized as the reserved keyword: "This recognition shall > > *only* occur...". It doesn't explain whether the reserved keyword can > > be really used to construct the AST foll

Re: syntax error while parsing a case command within `$(...)'

2021年2月16日(火) 19:24 Oğuz : > XRAT Shell Grammar ( > https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html#tag_23_02_10 > ) explains that giving almost the same examples as we posted in this thread. Thank you, interesting! So, if I understand correctly, the following construct

Re: syntax error while parsing a case command within `$(...)'

16 Şubat 2021 Salı tarihinde Koichi Murase yazdı: > 2021年2月16日(火) 19:24 Oğuz : > > XRAT Shell Grammar ( https://pubs.opengroup.org/ > onlinepubs/9699919799/xrat/V4_xcu_chap02.html#tag_23_02_10 ) explains > that giving almost the same examples as we posted in this thread. > > Thank you, interesti

Re: syntax error while parsing a case command within `$(...)'

2021年2月16日(火) 21:41 Oğuz : >> > XRAT Shell Grammar ( >> > https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html#tag_23_02_10 >> > ) explains that giving almost the same examples as we posted in >> > this thread. >> >> Thank you, interesting! So, if I understand correctly, the fol

Re: syntax error while parsing a case command within `$(...)'

On 2/16/21 12:29 AM, Oğuz wrote: 16 Şubat 2021 Salı tarihinde Koichi Murase > yazdı: bash -c ': $(case x in esac)' bash -c ': $(case x in (x) if :; then echo a; fi esac)' bash -c ': $(case x in (x) a() { echo a; } esac)' bash -c ': $(case x in (x) f

Re: syntax error while parsing a case command within `$(...)'

> XCU 2.10.2/(1) Shell Grammar Rules [Command Name] > > When the TOKEN is exactly a reserved word, the token identifier for > > that reserved word shall result. Otherwise, the token WORD shall be > > returned. Also, if the parser is in any state where only a reserved > > word could be the next corr

Re: syntax error while parsing a case command within `$(...)'

On Tue, Feb 16, 2021 at 5:34 PM Koichi Murase wrote: > Maybe Bash could insist that [[ ... ]] and ((...)) are not part of the > standard so that it can behave inconsistently. But it seems to me > that there is really no reason to behave inconsistently here. > They resemble `[ ... ]' (I know it'

Re: syntax error while parsing a case command within `$(...)'

Oğuz writes: >> Before we worry about what to change, I want to note that the original >> example is syntactically incorrect. The example is >> >> $ bash -c ': $(case x in x) esac)' >> >> But the manual page makes it clear that each case must be ended with >> ";;". > > `;;' is optional for the

Re: syntax error while parsing a case command within `$(...)'

> On Feb 16, 2021, at 10:42 PM, Dale R. Worley wrote: > >> Oğuz writes: >> >> `;;' is optional for the last case item. > > The manual page (for my version) says it's required. If, in some > certain circumstances, it works without, that's nice. It's also required by POSIX. > But there's no c