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! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
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 14:01:29 2024 UTC