|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79648 Control + Arrows not working in Interactive PHP `php -a`
Submitted: 2020-05-28 16:21 UTC Modified: 2020-05-28 17:11 UTC
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: d28b312d at opayq dot com Assigned:
Status: Open Package: Readline related
PHP Version: Irrelevant OS: Windows 10 + Cygwin
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: d28b312d at opayq dot com
New email:
PHP Version: OS:


 [2020-05-28 16:21 UTC] d28b312d at opayq dot com
The Cygwin PHP version is compiled with `libedit` which in itself isn't bad but it seems on Cygwin it's outputting symbols such as `;5C` and `;5D` instead of moving the cursor.

I have a valid inputrc file (used by bash for readline) and that works fine so for bash this is all working.

I tried creating an editrc file `~/.editrc` and it seems PHP doesn't load this, nor does it obey the `EDITRC` env var either.
bind "\e[1;5D" vi-prev-word
bind "\e[1;5C" vi-next-word

My `TERM` Is 'xterm-256color' and this happens on any terminal (mintty or cmd).

Expected result:
Control + Arrows to work

Actual result:
/c/src/somesource (master) [0] $ php -a
Interactive shell

php > ;5D;5C;5D;5C


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2020-05-28 17:11 UTC]
> The Cygwin PHP version is compiled with `libedit` […]

Why?  Did you ask the maintainers?
 [2021-06-25 16:10 UTC] vike2000 at gmail dot com
I've been fighting a similar issue, though in the context of using a Dockerfile w/ "FROM php:8.0-apache".

I generally prefer GNU Readline and on my host macOS-installation `php -a` (installed w/ MacPorts `port install php80 +readline`) works fine with my binds in `~/.inputrc`.
I don't think it's feasible to fork (and maintain) my own version of the Dockerfile, as suggested in the two issues linked via

I tried hacking-in `docker-php-ext-install readline` (via `apt-get -y install libreadline-dev`, patching `docker-php-ext-configure` to be able to move running `phpize` before removing a global `test "$PHP_LIBEDIT" = "no" && PHP_LIBEDIT=yes` (like hardcoded it's `PHP_LIBEDIT=yes`) and a similarly global `$as_echo "#define HAVE_LIBEDIT 1" >>confdefs.h` in `./configure`, and _then_ run `docker-php-ext-configure`).
I gave up when I found `#define HAVE_LIBEDIT 1` in `/usr/local/include/php/main/php_config.h` (ie asserting the php in Dockerfile w/ "FROM php:8.0-apache" is already built w/ editline?) which is included in the `readline.c`.

Sorry I can't come with any more clear conclusion.
Thanks to anyone who look into this. Not to be rude or whine but I guess most people accept bad REPL-editing?


(PS. I'm really trying to get eg `bind "^W" …` in `~/.editrc` working in Laravel `./artisan tinker` which uses PsySH.)
 [2021-06-27 18:01 UTC] vike2000 at gmail dot com gave me my "solution", namely an env export of eg `LD_PRELOAD=/lib/x86_64-linux-gnu/*` before running any php wrapper.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon May 20 06:01:34 2024 UTC