[PHP-DEV] php interactive shell without readline

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 interactive
shell without readline support).
There is an alternative readline replacement called linenoise (
https://github.com/antirez/linenoise/) 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?

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Well, I saw it, and I say for a ~600 line library, why not?

Heck, we could maybe reimplement the readline extension with it.

On 04/08/12 20:49, 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 interactive
> shell without readline support).
> There is an alternative readline replacement called linenoise (
> https://github.com/antirez/linenoise/) 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?
>

--
Andrew Faulds
http://ajf.me/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hello,

This project is interesting but it is also possible to do it only with PHP.
As a proof of concept, I would like to share some links with you. First
one:
http://hg.hoa-project.net/Central/file/tip/Library/Console/Readline/Readline.php,
which is highly hackable: we can add mappings (esc, ctrl, abc…), history
(when pressing key up and key down) and it works as an infinite
automaton based on the STATE_* constants. And thanks to PHP and its
static:: keyword, we can overload states, e.g.:
http://hg.hoa-project.net/Central/file/tip/Library/Console/Readline/Password.php.
Hop, password is hidden :-).
This library has some limitations: it does not support multibytes
(Unicode) and has an unlimited history (which can cause memory errors),
but it is a (advanced-)POC. It works on Unix-based system, actually
STTY-based shells, and has a pretty simple fallback for DOS. It does not
require PHP to be compiled --with-readline, it uses stty options
instead. And finally, it uses around 850 lines of codes (with comments +
licences).

Best regards :-).

On 04/08/12 21:50, Andrew Faulds wrote:
> Well, I saw it, and I say for a ~600 line library, why not?
>
> Heck, we could maybe reimplement the readline extension with it.
>
> On 04/08/12 20:49, 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 interactive
>> shell without readline support).
>> There is an alternative readline replacement called linenoise (
>> https://github.com/antirez/linenoise/) 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?
>>
>

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 05/08/12 19:33, Ivan Enderlin @ Hoa wrote:
> On 05/08/12 12:39, Andrew Faulds wrote:
>>
>> Great, but couldn't you type some command which would screw it up, by
>> accident?
> What do you mean?
>
Say your implementation uses some global variable called $history. Now
say I type "$history = [];" at the interactive prompt. Won't that break it?
>> Also I think UTF-8 (Unix) or UTF-16 (Windows) might be important.
> Exactly. I'm working on it.
>
> Best regards.
> --
> Ivan Enderlin
> Developer of Hoa
> http://hoa.42/ orhttp://hoa-project.net/
>
> PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
> http://disc.univ-fcomte.fr/ andhttp://www.inria.fr/
>
> Member of HTML and WebApps Working Group of W3C
> http://w3.org/


--
Andrew Faulds
http://ajf.me/

On 05/08/12 20:36, Andrew Faulds wrote:
> On 05/08/12 19:33, Ivan Enderlin @ Hoa wrote:
>> On 05/08/12 12:39, Andrew Faulds wrote:
>>>
>>> Great, but couldn't you type some command which would screw it up,
>>> by accident?
>> What do you mean?
>>
> Say your implementation uses some global variable called $history.
Not global variables but class attributes.

> Now say I type "$history = [];" at the interactive prompt. Won't that
> break it?
Of course not. We read chars one by one on stdin. If a mapping is
detected, then we call the associated callable. The line is never
executing/evaluating as a PHP code (except if this is what you want
obviously).

Cheers :-).

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

On 05/08/12 19:44, Ivan Enderlin @ Hoa wrote:
> On 05/08/12 20:36, Andrew Faulds wrote:
>> On 05/08/12 19:33, Ivan Enderlin @ Hoa wrote:
>>> On 05/08/12 12:39, Andrew Faulds wrote:
>>>>
>>>> Great, but couldn't you type some command which would screw it up,
>>>> by accident?
>>> What do you mean?
>>>
>> Say your implementation uses some global variable called $history.
> Not global variables but class attributes.
>
>> Now say I type "$history = [];" at the interactive prompt. Won't that
>> break it?
> Of course not. We read chars one by one on stdin. If a mapping is
> detected, then we call the associated callable. The line is never
> executing/evaluating as a PHP code (except if this is what you want
> obviously).
Eh? I thought PHP interactive evaluated the code? What's the use of only
being able to use functions?
>
> Cheers :-).
> --
> Ivan Enderlin
> Developer of Hoa
> http://hoa.42/ orhttp://hoa-project.net/
>
> PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
> http://disc.univ-fcomte.fr/ andhttp://www.inria.fr/
>
> Member of HTML and WebApps Working Group of W3C
> http://w3.org/


--
Andrew Faulds
http://ajf.me/

On 05/08/12 20:56, Andrew Faulds wrote:
> On 05/08/12 19:44, Ivan Enderlin @ Hoa wrote:
>> On 05/08/12 20:36, Andrew Faulds wrote:
>>> On 05/08/12 19:33, Ivan Enderlin @ Hoa wrote:
>>>> On 05/08/12 12:39, Andrew Faulds wrote:
>>>>>
>>>>> Great, but couldn't you type some command which would screw it up,
>>>>> by accident?
>>>> What do you mean?
>>>>
>>> Say your implementation uses some global variable called $history.
>> Not global variables but class attributes.
>>
>>> Now say I type "$history = [];" at the interactive prompt. Won't
>>> that break it?
>> Of course not. We read chars one by one on stdin. If a mapping is
>> detected, then we call the associated callable. The line is never
>> executing/evaluating as a PHP code (except if this is what you want
>> obviously).
> Eh? I thought PHP interactive evaluated the code? What's the use of
> only being able to use functions?
The code I presented only replace the readline functionnality (like
Linenoise does). Then you can evaluate the code with the help of a
temporary file, FastCGI & co., I don't know ;-).

Best regards :-).

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

On 05/08/12 22:03, Ivan Enderlin @ Hoa wrote:
> On 05/08/12 20:56, Andrew Faulds wrote:
>> On 05/08/12 19:44, Ivan Enderlin @ Hoa wrote:
>>> On 05/08/12 20:36, Andrew Faulds wrote:
>>>> On 05/08/12 19:33, Ivan Enderlin @ Hoa wrote:
>>>>> On 05/08/12 12:39, Andrew Faulds wrote:
>>>>>>
>>>>>> Great, but couldn't you type some command which would screw it
>>>>>> up, by accident?
>>>>> What do you mean?
>>>>>
>>>> Say your implementation uses some global variable called $history.
>>> Not global variables but class attributes.
>>>
>>>> Now say I type "$history = [];" at the interactive prompt. Won't
>>>> that break it?
>>> Of course not. We read chars one by one on stdin. If a mapping is
>>> detected, then we call the associated callable. The line is never
>>> executing/evaluating as a PHP code (except if this is what you want
>>> obviously).
>> Eh? I thought PHP interactive evaluated the code? What's the use of
>> only being able to use functions?
> The code I presented only replace the readline functionnality (like
> Linenoise does). Then you can evaluate the code with the help of a
> temporary file, FastCGI & co., I don't know ;-).
>
> Best regards :-).
Oh sorry, I got confused. I see.
> --
> Ivan Enderlin
> Developer of Hoa
> http://hoa.42/ orhttp://hoa-project.net/
>
> PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
> http://disc.univ-fcomte.fr/ andhttp://www.inria.fr/
>
> Member of HTML and WebApps Working Group of W3C
> http://w3.org/


--
Andrew Faulds
http://ajf.me/

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 interactive
> 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.

> There is an alternative readline replacement called linenoise (
> https://github.com/antirez/linenoise/) 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.

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. I'd
also like if readline can be built shared but still overwrite the
built-in default.

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 all
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?

johannes


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Mon, Aug 6, 2012 at 12:18 AM, Johannes Schlüter
<[email protected]>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 interactive
> > 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=53878 and
http://git.php.net/?p=php-src.git;a=commit;h=6c734a6b4c9ecf90162cf53fcf5f89864ccabbde
right?

>
> > There is an alternative readline replacement called linenoise (
> > https://github.com/antirez/linenoise/) 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 was
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 the
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 all
> 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. ;)

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

On 06/08/12 00:21, Ferenc Kovacs wrote:
> On Mon, Aug 6, 2012 at 12:18 AM, Johannes Schlüter
> <[email protected]>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 interactive
>>> 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=53878 and
> http://git.php.net/?p=php-src.git;a=commit;h=6c734a6b4c9ecf90162cf53fcf5f89864ccabbde
> right?
>
>>> There is an alternative readline replacement called linenoise (
>>> https://github.com/antirez/linenoise/) 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 was
> 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 the
> 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 all
>> 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?

--
Andrew Faulds
http://ajf.me/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Mon, 2012-08-06 at 00:22 +0100, Andrew Faulds wrote:
> > 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. ;)

I wonder which is the actual problem to solve? ;-)

Probably a better solution is to simply drop the -a mode without
readline and show a nice error message instead. Unix/Linux users should
have either libedit or readline around. For Windows this is still might
not be a complete solutions, last time I tried I failed with providing
inofficial readline builds (don't remember the problem) but maybe the
win folks can provide libedit based builds (we can't provide readline
based builds due to licensing)

> Well if linenoise() isn't that different, you could use #ifdefs to make
> it use the correct lib at compile-time, no?

That won't solve the issue that the extension might not be there (unless
you undo the refactoring in 5.4 which means there's no way to override
using readline anymore, as mentioned in my previous mail)

johannes


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Mon, Aug 6, 2012 at 1:22 AM, Andrew Faulds <[email protected]> wrote:

> On 06/08/12 00:21, Ferenc Kovacs wrote:
>
>> On Mon, Aug 6, 2012 at 12:18 AM, Johannes Schlüter
>> <[email protected]>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 interactive
>>>> 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=53878https://bugs.php.net/bug.php?id=53878and
>> http://git.php.net/?p=php-src.**git;a=commit;h=**
>> 6c734a6b4c9ecf90162cf53fcf5f89**864ccabbdehttp://git.php.net/?p=php-src.git;a=commit;h=6c734a6b4c9ecf90162cf53fcf5f89864ccabbde
>> right?
>>
>> There is an alternative readline replacement called linenoise (
>>>> https://github.com/antirez/**linenoise/https://github.com/antirez/linenoise/)
>>>> 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 was
>> 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 the
>> 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 all
>>> 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.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

On 06/08/12 00:37, Ferenc Kovacs wrote:
>
>
> On Mon, Aug 6, 2012 at 1:22 AM, Andrew Faulds <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 06/08/12 00:21, Ferenc Kovacs wrote:
>
> On Mon, Aug 6, 2012 at 12:18 AM, Johannes Schlüter
> <[email protected] <mailto:[email protected]>>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 interactive
> 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=53878 and
> http://git.php.net/?p=php-src.git;a=commit;h=6c734a6b4c9ecf90162cf53fcf5f89864ccabbde
> right?
>
> There is an alternative readline replacement called
> linenoise (
> https://github.com/antirez/linenoise/) 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 was
> 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 the
> 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 all
> 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 ?
No, I mean moving code bact to sapi/cli/php_cli.c and using either
readline or linenoise there as appropriate.
> 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.
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu


--
Andrew Faulds
http://ajf.me/