The readline library is used by a slew of command line interpreters, including bash, to provide a standardized way for users to write and edit command lines, and maintain histories.

Clauses in PHP's license make it incompatible with the GPL and therefore unable to be linked with the standard readline library, which is GPL-licensed. There is a BSD-licensed library called libedit which is meant to be a replacement for readline, however it is lacking in some functionality.

Due to licensing issues, Debian, Ubuntu, and perhaps other distros do not build their distributed versions of php to link with readline, and instead link it with libedit.

This topic has now come up in two different issues, #437568: Autocomplete awesomeness for drush and #543550: Drush interactive mode, so in order to help keep the discussion of those issues on topic I've created this one.

Comments

intuited’s picture

Issue tags: +readline, +dotdeb.org

Just some info gleaned from the other threads:

A build of php 5.2 against the readline library is said to be available at http://dotdeb.org. This was mentioned in #437568: Autocomplete awesomeness for drush comment #50, and also in the first comment of #437668: Changing the order of fields on node: title on second position?. I haven't tried this myself, and don't know eg if they make available a package for Ubuntu or just Debian.

intuited’s picture

Priority: Normal » Minor
Status: Needs review » Active

If the package at dotdeb.org doesn't work for you, these instructions may be useful. This should help you build a version of php that uses readline instead of libedit, but otherwise work as it normally does as per your distro.

This will replace any version of php on your system that was installed in the standard way through the apt system, eg via aptitude, synaptic, etc.

##
# First you need to install packages that will be used during the build process and afterwards.

$ sudo aptitude -r install build-essential devscripts
#   build-essential installs the compiler, make tool and other commodities 
#     central to the world of open source software
#   devscripts contains scripts to facilitate the building of debian-ish packages (.debs)

$ sudo aptitude -r build-dep php5     
#   This installs packages (prerequisites) that you'll need in order to install the built php5 packages

$ apt-get source php5
#   this will download the source and the distro-specific build info and patches for php5.


##
# At this point you're ready to start customizing the build as delivered by your distro

$ cd php*
#   this will be a directory with a name of the form "php5-$VERSION"

$ sed 's/--with-libedit/--with-readline/' debian/rules >/tmp/php-debian-rules
$ cp /tmp/php-debian-rules debian/rules
#   The file "debian/rules" governs how the php5 packages will be built by the debian packaging scripts.
#   These last two lines change references to libedit into references to readline.
#   In practice it's probably wiser to do this with an actual editor
#     so you can make sure nothing really weird is going on.
#   In my case, and I think this will be the norm, there was only one instance of the string "--with-libedit":
#     It was in the options to the c compiler to be used when compiling the CLI target.
#   Anyway just go through the debian/rules file and change where it says "--with-libedit" to read "--with-readline".

$ dch --local readline "local build with readline"
#   This just adds a new entry to the php5 debian package's changelog describing what you're doing.  
#   The "readline" parameter will be used to make the new version name.

$ debuild -us -uc 
#   This compiles the code and builds the .deb packages that will be deposited in the parent directory.
#   It takes a while.
#   The -us and -uc options tell it not to sign the package, which you want 
#     because you're not a maintainer who's going to be distributing it.
#   You can also add the '-b' (binary-only) option here, which specifies not to include the source.
#     I didn't bother but it might speed things up, or give smaller .deb files.

$ dpkg -i ../*.deb
#   This will install the packages you've just built in much the same way as running "aptitude install" does, 
#     but without the preliminary step of fetching packages from the repository first (and some other niceties)

##
# At this point, if you didn't get any error messages, you should be good to go.  Try this:
$ /usr/bin/php -v
#  I get:
PHP 5.2.6-2ubuntu4.3readline1 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 27 2009 22:10:40) 
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
    with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans

The dpkg line is sort of a brute-force method in that you end up installing php stuff that you may not need; it's probably better to pick and choose which debs you actually need to install.

You probably won't need to install the php5-dev package but if you do you will have to install the 'shtool' package:

$ sudo aptitude -r install shtool

The file debian/README.source mentions that if you install the php5-dbg.deb file, you will probably need to install some other packages first, and that you can get a list of likely suspects by doing

$ dh_testdir && egrep '^Package' debian/control | cut '-d ' -f2 | \
	egrep -v '(^php5|dbg|dev|common|pear)$' | tr "\n" "|" | sed 's/|$//' |\
	sed -r 's/([^|]+)(\||$)/ \1 (= ${binary:Version}) \2/g'; echo

But you should already have those installed if you've already installed that package through aptitude. In general if you have dependency problems when running dpkg, it's because you're installing packages that aren't already installed on your system; maybe try `aptitude search '~n^php' |grep '^i'` to see what's actually installed, and then just run dpkg -i on your locally-built versions of those packages and the php packages they depend on. EG install the core package first and then cli and whatever else you need.

If something goes wrong, or you would like more background info, I found this guide from the Debian website to be a good reference for working with .deb packages. Section 7.14 is particularly relevant.

Hope this helps!

jonhattan’s picture

for completeness: densite module has had also issues with readline: #501056: requires readline support in php-cli but debian lenny has no readline support for it's php-cli package

Also to note that debian does not provide php with libedit. Is just ubuntu who provides php with libedit.

I think this issue could be converted to a documentation page in drush code (perhaps an appendix to README.txt) or the drush handbook.

In the general term could be of interest to provide a drush_readline() to unify efforts on distinct commands. Zenophile is also moving to drush (#445608: Add drush commands for sub-theme creation) and they will also need some readline.

Garrett Albright’s picture

For the record, Zenophile doesn't need readline. I'm not sure why it would…

jonhattan’s picture

I mean zenophile, as a command that receives user input interactively, could benefit of readline.

Garrett Albright’s picture

It doesn't receive user input interactively, though. It just takes command line arguments like most other Drush commands.

intuited’s picture

Having readline available would be helpful to people who are dropping into a php shell, ie read-eval loop of some variety, from within drush. This was my major motivation to get php-readline working, as it's a super convenient way to test code and explore the API. There are a few different shells out there (phpsh, php_shell, etc) that may be pretty easy to just drop into from a drush command; I've written a drush module with basic shell functionality and some completion that seems to be growing into a project in its own right, and ought to be integrated with the 'drush cli' command's code somehow.

izkreny’s picture

Subscribing.

jennifer.chang’s picture

subscribe.

jhr’s picture

Status: Active » Closed (fixed)

no progress in 2 years... start another thread ...
novice triaged - feel free to reopen

jennifer.chang’s picture

Status: Closed (fixed) » Active

fixed?

greg.1.anderson’s picture

Status: Active » Closed (won't fix)

No, won't fix.

owen barton’s picture

For anyone curious, the primary issue with libedit was resolved some time ago https://bugs.launchpad.net/ubuntu/+source/php5/+bug/322214