[MacPorts] #52866: sqlite3: unable to enter non-ASCII characters

[MacPorts]

#52866: sqlite3: unable to enter non-ASCII characters
------------------------------+-------------------
  Reporter:  raimue           |      Owner:  mww@…
      Type:  defect           |     Status:  new
  Priority:  Normal           |  Milestone:
 Component:  ports            |    Version:
Resolution:                   |   Keywords:
      Port:  sqlite3 libedit  |
------------------------------+-------------------
Changes (by raimue):

 * cc: MarcusCalhoun-Lopez (added)
 * port:  sqlite3 => sqlite3 libedit


Comment:

 Hm, it seems to be using `-I/opt/local/include` with the compile command,
 which would contain `readline/readline.h` and thus should take precedence?

 That you cannot select readline is caused by the patch to the configure
 script that forces `-ledit` to be tried before `-lreadline`. And in fact,
 if I leave out the patch, `--enable-readline --disable-editline` produces
 a sqlite3 that accepts wide characters.

 Turns out this is in fact a issue with our libedit. The readline()
 compatiblity interface does not seem to accept these characters. Note that
 this works with the libedit provided by macOS, so I would assume it is a
 bug in libedit itself.

 Here is a small test program with a shell sequence to test it:

 {{{
 $ cat > readline-test.c
 #include <editline/readline.h>

 int main() {
     char *line = readline("test: ");
     printf("%s\n", line);
     return 0;
 }
 $ clang -o readline-test-apple readline-test.c -ledit
 $ clang -I/opt/local/include -L/opt/local/lib -o readline-test-macports
 readline-test.c -ledit
 $ ./readline-test-apple
 test: Müller
 Müller
 $ ./readline-test-macports
 test: Mller
 Mller
 }}}

--
Ticket URL: <https://trac.macports.org/ticket/52866#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS