Bad tokenisation inside backticks

[Adam Sampson]

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/opt/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -O2
uname output: Linux cartman.at.offog.org 2.6.18-rt5-GS #1 SMP PREEMPT Mon Oct 2 
14:56:34 BST 2006 i686 GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 3.2
Patch Level: 0
Release Status: release

Description:
        bash 3.2.0 appears to handle hashes inside strings inside backticks in
        an unexpected way; this wasn't the case with previous versions as far
        as I can tell.
        
        Specifically, one of the scripts in the ncurses distribution does this:
        
        TABSIZE=`grep -v '^[ #]' $CAPS | grep -v "^$" | grep -v "^capalias"| 
grep -v "^infoalias" | wc -l`
        
        which causes bash 3.2.0 to fail with:
        
        work/ncurses-5.6/include/MKhashsize.sh: line 38: unexpected EOF while 
looking for matching ``'

Repeat-By:
        Do this at the bash prompt:
        
        x=`echo " #"`
        
        With bash 3.1.17 and 3.1.0, this works as expected; x gets the value " 
#".
        With bash 3.2.0, you get the ">" prompt; doing it in a script reveals
        that bash is looking for a matching backtick.