php (via libedit using_history()) incorrectly opens stdin

I can confirm this problem in Jaunty (5.2.6-2ubuntu5), Intrepid (5.2.6-2ubuntu4) and Hardy (5.2.4-2ubuntu5.4). Well, at least I can confirm the symptom.

The versions in Gutsy (5.2.3-1ubuntu6.4) and Dapper (5.1.2-1ubuntu3.12) seems to be working fine.

I suspect this bug might somehow be related to libedit, which was (re)introduced into php5-cli in Hardy.

I downloaded the source packages of php on Hardy as well as on Jaunty, removed "--with-libedit" from debian/rules and rebuilt the packages. When I had installed the new binaries "php -i | less" worked just the way you would expect it to.

I am also seeing this in Ubuntu Server 9.04 and php5-cli 5.2.6.dfsg.1-3ubuntu4

This also breaks the ability to use php within bash "complete -F" function code (used for shell auto-completion). I have attached a test case (test instructions and expected/actual results are comments in the file). I am using the Jaunty PHP - PHP 5.2.6-3ubuntu4.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 23 2009 14:35:05). I have tested with the http://www.dotdeb.org/ PHP 5.3 rc2 build (which I am pretty sure would use readline) and it functions correctly there.

For reference, the upstream issue where I discovered this behaviour is at http://drupal.org/node/437568#comment-1640730

This bug, which is still present in Ubuntu Server 9.10, makes php development on ubuntu much more difficult.

Piping long output streams into a pager is a standard part of any developer's day-to-day work, and php usage from the command line is essential to many users.

I'd like to see this bug made a higher priority, particularly since it appears to be relatively simple in nature, and php's output is fine in other gnu/linux distros. We shouldn't have to all rebuild our php packages just to get the basics working properly.

Sorry to be so critical, but this bug has been around for almost a year, and is very frustrating.

Just to confirm, this is still present as of php5-cli 5.3.3-1ubuntu3

I've taken a good long look at this, and I am 99.9% sure that this is a problem with libedit..

#include <stdio.h>
#include <histedit.h>

int main(int argc, char *argv[])
{
    using_history();
    printf("Some interesting info\n");
    return 0;
}

This program, compiled with 'gcc test.c -ledit -o test'

Will produce the exact same effect when piped to less.

using_history() is called in the init function of the readline extension at line 168 of ext/readline/readline.c

The reason this didn't break in the standard PHP build is most likely that libedit wasn't used, as readline is an optional module.

I reported it here:

https://sourceforge.net/tracker/?func=detail&aid=3044367&group_id=18314&atid=118314

But that tracker appears to be dead. Also sent report to the Debian Maintainer, and will mark it as also affecting libedit. I tested it with the GNU readline library's using_history(), and that did not exhibit the same problem.

One possible workaround is to build readline as an extension, and not load it by default. I suspect though that any packages that have php scripts that need/want readline would be fairly broken then. Another method is to have the readline extension make sure it lets go of the terminal if libedit is used.

This seems to be the same (very old) bug in debian

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286356

While looking at this, I gave my test program a try on NetBSD 5.0.2, and the terminal is handled correctly, so this may be specific to glibc and/or linux terminal I/O.

Settings tatus of the php5 task back to Confirmed. This needs to be forwarded upstream to PHP before it is considered Triaged.

Ok so the real problem is actually this:

ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0

When this happens, the terminal is under control and less can't take it. I've proposed a patch to libedit to avoid doing this if stdout is not a tty, and forwarded it along to the upstream mailing list for discussion there. I will also propose a merge shortly.

Note that neither Debian Lenny (php5-cli 5.2.6.dfsg.1-1+lenny10) nor Debian Squeeze (php5-cli 5.3.3-7+squeeze1) have this problem; Upcoming 11.04 Natty Narwhal still does have it, as you know.

Thanks for your work on this @Clint

The problem still exists on 11.10.

FYI, the upstream thread is here:

http://mail-index.netbsd.org/tech-userlevel/2011/01/26/msg004486.html

And I got one positive response. However, it does not appear that the patch ever landed upstream.

Since this is linux specific, I think we can have this as a patch to libedit and carry it as part of libedit's port to linux. So I've uploaded the fix to precise.

This bug was fixed in the package libedit - 2.11-20080614-3ubuntu1

---------------
libedit (2.11-20080614-3ubuntu1) precise; urgency=low

  * libedit/tty.c: grabs controlling terminal even when output is a non
    tty, causing things like php | less to mis-function. Patch changes
    this behavior to work more like readline. (LP: #322214)
 -- Clint Byrum <email address hidden> Wed, 26 Jan 2011 13:04:09 -0800

Closing the PHP task.. its not really fixable in PHP.