Bash completion sometimes meshes up my terminal

[Jaro Punta]

I am not sure this is a bug but I cannot find an explanation why this
happens. Sometimes when I execute certain commands, and I press the
Tab key while I am typing the command, then after the commands
finishes, the terminal is left in a abnormal state (e.g. terminal echo
is off). This seems to happen when the program in the command has an
associated completion function that performs certain actions, such as
calling grep. Here's a concrete example:

1. Create the file /tmp/test_bashrc with the following contents:

        _completion_test() {
            grep -q foo /dev/null
            #cat /dev/null
            return 1
        }
        complete -F _completion_test yes
        complete -F _completion_test find
        complete -F _completion_test rlwrap

2. Start a clean bash session with "bash --norc" to ensure that no
external completion rules are loaded.

3. Source  /tmp/test_bashrc to load the completion rules from there.

4. Type the following *exactly*: "yes ", followed by a tab, followed
by "| head", followed by enter. That is, type the *exact* sequence of
keys: y e s SPACE TAB | SPACE h e a d ENTER. When the command
completes, the terminal will be messed up (e.g. echo will be off) and
you will need to type something like "stty sane" to fix it.

Now the weird part is that if I remove the grep line from the
completion function, this doesn't happen anymore and everything works
just fine. The problem also happens when I replace the grep line with
something seemingly harmless such as "cat /dev/null".
Here are some alternative commands that exhibit the same problematic behavior:

4a. Type "find /\t| head\n", i.e. f i n d SPACE TAB | SPACE h e a d ENTER.

4b. Type "rlwrap cat" followed by tab and then enter. Then kill the
command with Ctrl-C.

Note, my actual completion function looks more like that:

        _completion_test() {
            if grep -q "$1" /some/file; then
                # put some values in COMPREPLY
            else
                return 1
           fi
        }

but that doesn't seem to matter; a mere call to grep (or cat) causes
the problem.

Finally, here's what bashbug has to say about my system:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H   -I. -I./include -I. -I./include -I./lib
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
-DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin'
-DSYS_BASHRC='/etc/bash/bashrc'
-DSYS_BASH_LOGOUT='/etc/bash/bash_logout'
-DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -DUSE_MKTEMP
-DUSE_MKSTEMP -O2 -march=native -pipe
uname output: Linux XXX 4.4.17 #7 SMP PREEMPT Sat Aug 13 12:58:33 XXX
2016 x86_64 Intel(R) Core(TM) iX-XXXXX CPU @ X.XXGHz GenuineIntel
GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.3
Patch Level: 46
Release Status: release