php (via libedit using_history()) incorrectly opens stdin

Bug #322214 reported by Edward Z. Yang
50
This bug affects 7 people
Affects Status Importance Assigned to Milestone
libedit (Debian)
Fix Released
Unknown
libedit (Ubuntu)
Fix Released
Undecided
Unassigned
php5 (Ubuntu)
Invalid
Low
Clint Byrum

Bug Description

Binary package hint: php5

PHP appears to be opening stdin improperly. You can see the behavior by running:

$ php -i | less

Notice how less does not redraw the screen correctly, and pressing the up or down arrow keys results in ^[OB being written to the bottom of the screen. I think that this is because of a race condition between php and less. The following command does not have the problem:

$ php -i < /dev/null | less

This has been reproduced on Ubuntu 8.10 Intrepid as well as a clean Ubuntu 8.04 Hardy machine (with php-cli installed first, of course). It could not be reproduced on Debian 4.0 etch, or a minimal, clean build of PHP 5.2 off of the CVS source tree (on intrepid). I suspect one of Ubuntu's patches is causing this problem, but I don't know which.

The PHP package version is 5.2.6-2ubuntu4

Related branches

Revision history for this message
Andreas Olsson (andol) wrote :

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.

Changed in php5:
status: New → Confirmed
Revision history for this message
Andreas Olsson (andol) wrote :

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.

Revision history for this message
Gena01 (gena01) wrote :

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

Andreas Olsson (andol)
Changed in php5 (Ubuntu):
importance: Undecided → Low
Revision history for this message
Grugnog (grugnog) wrote :

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

Revision history for this message
Matthew James Goins (mjgoins) wrote :

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.

Changed in php5 (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Clint Byrum (clint-fewbar) wrote :

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.

Changed in libedit (Ubuntu):
status: New → Triaged
summary: - php incorrectly opens stdin
+ php (via libedit update_history()) incorrectly opens stdin
summary: - php (via libedit update_history()) incorrectly opens stdin
+ php (via libedit using_history()) incorrectly opens stdin
Revision history for this message
Clint Byrum (clint-fewbar) wrote :

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

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

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

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.

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

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

Changed in php5 (Ubuntu):
status: Triaged → Confirmed
Changed in php5 (Ubuntu):
assignee: nobody → Clint Byrum (clint-fewbar)
Revision history for this message
Clint Byrum (clint-fewbar) wrote :

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.

Revision history for this message
Randy Fay (randyfay) wrote :

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

Revision history for this message
Christian Weiske (cweiske) wrote :

The problem still exists on 11.10.

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in libedit (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Clint Byrum (clint-fewbar) wrote :

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

Changed in php5 (Ubuntu):
status: Confirmed → Invalid
Changed in libedit (Debian):
status: Unknown → Confirmed
Changed in libedit (Debian):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.