weird bash5 bug with ``for i; do echo; done; echo in''
Hi Chet, Today I compiled bash5 (using default configuration) from the devel branch (f602026a0ce - commit bash-20180316 snapshot) on macOS and found it breaks one of my rc files. After some time of debugging I have the following minimal example to reproduce the problem: $ bash5 -c 'for i; do echo; done; echo in' bash5: -c: line 0: syntax error near unexpected token `in' bash5: -c: line 0: `for i; do echo; done; echo in' $ Please take a look. -clark
Re: weird bash5 bug with ``for i; do echo; done; echo in''
On Sat, Mar 24, 2018, 11:45 AM Clark Wang wrote: > Hi Chet, > > Today I compiled bash5 (using default configuration) from the devel branch > (f602026a0ce - commit bash-20180316 snapshot) on macOS and found it breaks > one of my rc files. After some time of debugging I have the following > minimal example to reproduce the problem: > > $ bash5 -c 'for i; do echo; done; echo in' > bash5: -c: line 0: syntax error near unexpected token `in' > bash5: -c: line 0: `for i; do echo; done; echo in' > $ > > Please take a look. > > -clark > Confirmed on macOS Sierra and Ubuntu 17.10. >
Re: weird bash5 bug with ``for i; do echo; done; echo in''
On Sat, Mar 24, 2018, 12:23 PM Dennis Williamson < dennistwilliam...@gmail.com> wrote: > > > On Sat, Mar 24, 2018, 11:45 AM Clark Wang wrote: > >> Hi Chet, >> >> Today I compiled bash5 (using default configuration) from the devel branch >> (f602026a0ce - commit bash-20180316 snapshot) on macOS and found it breaks >> one of my rc files. After some time of debugging I have the following >> minimal example to reproduce the problem: >> >> $ bash5 -c 'for i; do echo; done; echo in' >> bash5: -c: line 0: syntax error near unexpected token `in' >> bash5: -c: line 0: `for i; do echo; done; echo in' >> $ >> >> Please take a look. >> >> -clark >> > > Confirmed on macOS Sierra and Ubuntu 17.10. > bash5 -c 'for i; do echo in; done' fails in the same way. >
Re: weird bash5 bug with ``for i; do echo; done; echo in''
On Sat, Mar 24, 2018 at 06:05:07PM +, Dennis Williamson wrote: [...] > >> $ bash5 -c 'for i; do echo; done; echo in' > >> bash5: -c: line 0: syntax error near unexpected token `in' > >> bash5: -c: line 0: `for i; do echo; done; echo in' [...] > bash5 -c 'for i; do echo in; done' > > fails in the same way. A shorter reproducer: for i do : in; done f698849a75fc781472806182c3dc930077a5d828 is the last known good commit that behaves correctly. It seems like the changes committed in 124d67cde092330257c69e8c9bd64af40ffd9b73 (http://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=124d67cde092330257c69e8c9bd64af40ffd9b73) introduced this problem: | 3/25 | | parse.y | - read_token_word: if we read a WORD immediately after a CASE, FOR, or | SELECT, increment `expecting_in_token' to note that we're going to | be reading IN as the next non-newline token | - special_case_tokens: if we're expecting an IN (expecting_in_token > 0) | and we have an "in", return IN and decrement expecting_in_token. This | is a better implementation of Posix grammar rule 6 than the previous | code in that function (which is still there for posterity, but should | eventually be removed). Fixes bug reported by Torka Noda | The following is not a fix, but it does make the problem go away: diff --git a/parse.y b/parse.y index 29b59f81..9efcc4aa 100644 --- a/parse.y +++ b/parse.y @@ -5315,7 +5315,7 @@ got_token: if (word_top < MAX_CASE_NEST) word_top++; word_lineno[word_top] = line_number; - expecting_in_token++; + //expecting_in_token++; break; } The problem is that expecting_in_token is increased unconditionally for a `for' statement, but the `in WORD' part of the loop is optional, so this confuses the parser.
odd error from bash exec binary on cmd line
Using bash-4.4.12... If I use bash -c, I get a variety of correct messages: bash -c xxx bash: xxx: command not found touch xx Ishtar:law/bin> bash -c xx bash: ./xx: Permission denied or when it works, it just does: bash -c "sleep 1" (sleeps 1) but if I leave off the '-c', like: bash sleep 1 I get: /usr/bin/sleep: /usr/bin/sleep: cannot execute binary file ??? Isn't it bash that cannot execute the binary file because it expected a script? Shouldn't bash be to the left of the ':' with some error on the right, like "cannot exec binary file" or "expected script file"?
