This seems to have to do with the readline() function in PHP rather than MediaWiki. Executing php -r 'var_dump( readline( "> " ) );' on terbium exhibits the same behavior, both with php5 (5.5.9+dfsg-1ubuntu4.20) and HHVM (3.12.7+dfsg-1+wmf1~trusty1).

On tin, which is Debian jessie rather than Ubuntu trusty, HHVM (3.12.7+dfsg-1+wmf4) and PHP (5.6.29+dfsg-0+deb8u1) both exhibit the issue. Although here PHP doesn't beep when attempting to enter the character like it does on terbium and with HHVM. I get the same results for the same version of PHP on a personal machine also running Debian jessie.

Locally on Debian sid, php5 (5.6.26+dfsg-1) and php7.0 (7.0.14-2) allow input of non-ASCII characters, but HHVM (3.12.11+dfsg-1) does not (and does not beep).

eval.php should just be killed and replaced with something decent. See T117661: Integrate a modern php REPL shell with MediaWiki.

chose and triaged T117661 over this task for the developer wishlist

Let's merge this (and make a note in the other task to make sure Unicode works). T117661 solves this and has a much wider audience.

PHP uses libedit by default for licensing reasons (you can check via the constant READLINE_LIB which is being used). libedit has Unicode support but it's not enabled by default. Debian enabled it in 3.1-20130712-2 (see bug 737786); trusty uses 3.1-20130712-2 (see libedit page). Xenial uses a newer version so recently installed vagrant boxes should be OK. For Debian, jessie should be OK, older releases not.

Options for getting it work on older boxes:

• try to get the trusty package updated (I don't think we care enough since we are moving away from trusty and both xenial and jessie work)
• recompile PHP to use readline instead (not something we'd want to do in puppet)
• use non-readline/libedit input (see patch above, IMO not worth it unless you really, really need non-ASCII)

If you only need unicode occasionally, you can always just run something like $str = trim(fgets(fopen('php://stdin', 'r'))); from the prompt.

In T69924#2959822, @Anomie wrote:

Locally on Debian sid, php5 (5.6.26+dfsg-1) and php7.0 (7.0.14-2) allow input of non-ASCII characters, but HHVM (3.12.11+dfsg-1) does not (and does not beep).

Same on Ubuntu Xenial (HHVM version is 3.11.1+dfsg-1ubuntu1).

So it seems there is both a system library issue (on its way out) and a HHVM issue blocking this task.

Note mwscript is hardcoded to use php5 (i.e. Zend, not HHVM). That is the subject of T146285.

Under HHVM on terbium, unicode can't be entered either:

sudo -u www-data hhvm /srv/mediawiki-staging/multiversion/MWScript.php eval.php --wiki=testwiki

On Debian they both depends on libedit2 anyway.

In T69924#3059560, @hashar wrote:

Under HHVM on terbium, unicode can't be entered either:

That will go away when T143536 is fixed. IMO all that's left here is for someone to re-test on HHVM master and file a bug report.

Unicode (äö) works for me now on HHVM 3.18.0 with both eval.php and shell.php (On Ubuntu 16.04).

Can you try with something that's not in Latin1, just in case?

I don't think I can actually type outside latin1 with keyboard layouts currently enabled, but with copy-pasting it works:

Thanks. In that case this task can be closed as declined IMO, the only other thing that could be done is to backport the HHVM fix to the version used by WMF, and that doesn't seem worth the effort.