bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: weird bash5 bug with ``for i; do echo; done; echo in''


From: Eduardo A . Bustamante López
Subject: Re: weird bash5 bug with ``for i; do echo; done; echo in''
Date: Sat, 24 Mar 2018 12:52:10 -0600
User-agent: Mutt/1.9.4 (2018-02-28)

On Sat, Mar 24, 2018 at 06:05:07PM +0000, 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
|         <address@hidden>


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]