Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62057
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <501F0047.9080005@ajf.me>
References: <CAH-PCH7QP-XxS3=+if7yoVNmCfiM4+HOhwOCDzSVJNsFEMCWRg@mail.gmail.com>
	<1344205126.1440.1086.camel@guybrush>
	<CAH-PCH5FmkjT+x7FpRo9C-_56reqo-m+ays3nN4b9Whpyz4AMQ@mail.gmail.com>
	<501F0047.9080005@ajf.me>
Date: Mon, 6 Aug 2012 01:37:53 +0200
Message-ID: <CAH-PCH6TKf-7pnh_af6wMOxoC0OG4ox3_tniPYtc+hfM-AQrpA@mail.gmail.com>
To: Andrew Faulds <ajf@ajf.me>
Cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf307f3112fe14de04c68d3f6d
Subject: Re: [PHP-DEV] php interactive shell without readline
From: tyra3l@gmail.com (Ferenc Kovacs)

--20cf307f3112fe14de04c68d3f6d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 6, 2012 at 1:22 AM, Andrew Faulds <ajf@ajf.me> wrote:

> On 06/08/12 00:21, Ferenc Kovacs wrote:
>
>> On Mon, Aug 6, 2012 at 12:18 AM, Johannes Schl=C3=BCter
>> <johannes@schlueters.de>wrote:
>>
>>  On Sat, 2012-08-04 at 21:49 +0200, Ferenc Kovacs wrote:
>>>
>>>> Hi,
>>>>
>>>> As most of you know, the current php interactive shell is pretty much
>>>> useless without compiling php --with-readline, but for the most users
>>>>
>>> this
>>>
>>>> the first impression what they experience (eg. using the php interacti=
ve
>>>> shell without readline support).
>>>>
>>> Note that for 5.4 I refactored the code so a shared readline extension
>>> is good enough by moving all shell related parts to ext/readline. This
>>> should reduce the pain for distribution package users where typically
>>> everything is shared.
>>>
>>>  for the record that would be https://bugs.php.net/bug.php?**id=3D53878=
<https://bugs.php.net/bug.php?id=3D53878>and
>> http://git.php.net/?p=3Dphp-src.**git;a=3Dcommit;h=3D**
>> 6c734a6b4c9ecf90162cf53fcf5f89**864ccabbde<http://git.php.net/?p=3Dphp-s=
rc.git;a=3Dcommit;h=3D6c734a6b4c9ecf90162cf53fcf5f89864ccabbde>
>>   right?
>>
>>  There is an alternative readline replacement called linenoise (
>>>> https://github.com/antirez/**linenoise/<https://github.com/antirez/lin=
enoise/>)
>>>> written by the author of Redis,
>>>>
>>> and
>>>
>>>> I would like to know, what do you think about using that for the
>>>> interactive shell if php is built without readline support.
>>>> It is really small/compact and it is under the two clause BSD license =
so
>>>>
>>> I
>>>
>>>> think it would be a good candidate for bundling it in php.
>>>> What do you think about it? Is it something worth looking into?
>>>>
>>> There are two ways to do that: Either move the shell code back to
>>> sapi/cli or making ext/readline play nice with linenoise.
>>>
>>>  I have to grasp the code a little bit better to answer that, but from =
a
>> quick look I think that it was an improvement, that the readline stuff w=
as
>> moved out from there, so I think that we should keep that.
>> The linenoise would be always available and I think it would be only a
>> couple of lines, so I think that it would be possible to put it into
>> php_cli.c but as you mentioned we should make it such a way, that even t=
he
>> dynamically loaded readline has to be able to override it.
>>
>>
>>  When using the first approach make sure that the user can still pick
>>> readline, as readline has features linenoise (currently) hasn't, like
>>> searching using Ctrl+r or configuration of the key combinations.
>>>
>>
>> agree, linenoise can't replace readline, so in general I think that we
>> should only use it, if readline isn't available.
>>
>>
>>  I'd
>>> also like if readline can be built shared but still overwrite the
>>> built-in default.
>>>
>>>  agree
>>
>>
>>  Doing the second approach has the benefit that the lib can be exported
>>> to userland in the same run. While then there's little benefit as it al=
l
>>> still depends on an extension ...
>>>
>>> (Actually there would be a third possibility - writing a linenoise
>>> extension which uses sapi/cli's hook but that requires duplicating most
>>> of the shell code and makes things more complicated, let#s ignore
>>> this ;-) )
>>>
>>> What's your plan there?
>>>
>>>
>>>  to tell you the truth I'm just throwing around ideas and waiting for
>> somebody with better understanding the actual implementation to help me
>> out. ;)
>>
>>  Well if linenoise() isn't that different, you could use #ifdefs to make
> it use the correct lib at compile-time, no?
>
>
you mean putting the #ifdefs in ext/readline/readline_cli.c ?
yeah that would be easy, but that would be both hackish and doesn't solve
anything, as that ext won't be loaded if readline isn't present.
this is why Johannes said, that we have to either move some code back to
sapi/cli/php_cli.c or integrate linenoise in such a way, that dynamically
loaded extensions could still replace/override it(else we would lose
Johannes work in 5.4 which made it possible to dynamically load readline).
Johannes, please correct me if I'm factually wrong here.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--20cf307f3112fe14de04c68d3f6d--