Fix bug #81280 refuse to allow unicode chars in prompts

[krakjoe]

Fixes https://bugs.php.net/bug.php?id=81280, https://bugs.php.net/bug.php?id=76989.

[krakjoe]

I've done a bit of digging ... my version of libedit does not support wide chars, however there have been patched versions of readline and or libedit that may handle unicode characters. In the "official" source it's not supported, and since it may result in a fault, we should disable wide chars by default as this patch does for consistency.

My version of libedit does not even allow me to input unicode characters, and so the patch for phpdbg is not strictly needed. I don't know how libedit/readline may behave elsewhere, so I've duplicated the behavior for phpdbg.

[nikic]

Any info on what breaks in libedit with utf-8? This seems super weird to me in that I'd expect unicode to work here if you simply didn't do anything special for it.

[krakjoe]

Program received signal SIGSEGV, Segmentation fault.
prompt_print (el=el@entry=0x5555575ef1d0, op=op@entry=0) at prompt.c:99
99	prompt.c: No such file or directory.
(gdb) back
#0  prompt_print (el=el@entry=0x5555575ef1d0, op=op@entry=0) at prompt.c:99
#1  0x00007ffff77086e2 in re_refresh (el=el@entry=0x5555575ef1d0) at refresh.c:267
#2  0x00007ffff7707bcb in read_prepare (el=0x5555575ef1d0) at read.c:434
#3  read_prepare (el=0x5555575ef1d0) at read.c:420
#4  0x00007ffff7707fed in el_wgets (el=el@entry=0x5555575ef1d0, nread=nread@entry=0x7fffffffc834) at read.c:508
#5  0x00007ffff7703267 in el_gets (el=0x5555575ef1d0, nread=nread@entry=0x7fffffffc834) at eln.c:75
#6  0x00007ffff771603e in readline (p=0x7ffff5264118 "»»»»> ") at readline.c:459
#7  0x0000555555d23d60 in readline_shell_run () at /opt/src/php-src/ext/readline/readline_cli.c:639
#8  0x00005555562f9b5d in do_cli (argc=3, argv=0x555557439290) at /opt/src/php-src/sapi/cli/php_cli.c:963
#9  0x00005555562fb51d in main (argc=3, argv=0x555557439290) at /opt/src/php-src/sapi/cli/php_cli.c:1367

This is a trace from my version of editline/libedit, it's old enough (but the default in ubuntu 20.10) that it simply doesn't have unicode support implemented - this is a well documented problem in many projects.

The source code for a version of libedit/editline at https://thrysoee.dk/editline/ says and reads like it supports unicode.

The problem seems to be that there are several different versions of editline/libedit and there's no good way to tell what features are available, short of doing a build test in config.

Since I don't view this as especially important to support where libedit/editline is able, it seems valuable for behavior to be consistent.

[krakjoe]

bump @nikic

FTR I looked at doing an AC_TRY_RUN like test to determine if the libedit/editline/readline being used would fault, however it doesn't look possible (in a portable way) to provide stdin to the test binary, and since readline() will block it doesn't look like we can test as part of configure process.

[krakjoe]

Ta, merged as a2e0519