php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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
Votes:1
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 Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: d28b312d at opayq dot com
New email:
PHP Version: OS:

 

 [2020-05-28 16:21 UTC] d28b312d at opayq dot com 
Description:
------------
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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-05-28 17:11 UTC] cmb@php.net 
> 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 https://github.com/docker-library/php/issues/717#issuecomment-421433322

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?

Cheerio,
vike

(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 
https://stackoverflow.com/questions/28003239/typing-unicode-characters-into-php-interactive#comment44417638_28003239 gave me my "solution", namely an env export of eg `LD_PRELOAD=/lib/x86_64-linux-gnu/libreadline.so.*` before running any php wrapper.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 19:01:29 2024 UTC