programs (like php -a) that put even a dumb terminal in bracketed-paste mode confuse rlwrap

[hanslub42]

rlwrap is not good at (and, to be honest, also not meant for) handling programs that write control codes to the terminal

For example rlwrap -a bash will make a horrible mess. But usually, those programs use termcap or terminfo to look up said control codes and thus quickly discover that those don't exist on a dumb terminal.

Which is why rlwrap -a -t dumb bash yields a much better experience.

However, the control codes for bracketed-paste are not part of termcap or terminfo and so have to be hard-coded into the program (rlwrap does this as well)

However, by doing this, many programs forget that bracketed-paste doesn't make sense on a dumb terminal and output the control code \e[?2004h anyway.

Which is why rlwrap -a -t dumb php -a still acts funny.

By the way, readline itself gets this right, cf the comment in terminal.c:

/* There's no way to determine whether or not a given terminal supports                                                                           
    bracketed paste mode, so we assume a terminal named "dumb" does not. */
if (dumbterm)
      _rl_enable_bracketed_paste = 0;

To do: improve the filter scrub_prompt to handle \e[?2004h and its ilk (now it only removes the \e)

Maybe: always remove those (paste handling is rlwraps business anyway, as specified in .inputrc, and not the wrapped program's anymore)

[hanslub42]

To do: improve the filter scrub_prompt to handle \e[?2004h and its ilk (now it only removes the \e)

Done, cf. f5c808f