Req #52052 [Opn->Asn]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 Updated by: f...@php.net Reported by: ef-lists at email dot de Summary: add syslog support to FPM -Status: Open +Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) -Assigned To: +Assigned To: fat Previous Comments: [2010-06-11 18:10:10] ef-lists at email dot de Description: At current, FPM only allows logging to local files, both for the ErrorLog and SlowLog. Using syslog aids the administrator greatly in centralizing logfiles. Also PHP itself has syslog support, so FPM should consequently have it, too. I hereby ask to add syslog support to FPM. -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Bug #49867 [Com]: spl_autoload crashes when called in write function of custom sessionSaveHandler
Edit report at http://bugs.php.net/bug.php?id=49867&edit=1 ID: 49867 Comment by: zapparov at member dot fsf dot org Reported by: nicolas dot lepage at yahoo dot fr Summary: spl_autoload crashes when called in write function of custom sessionSaveHandler Status: No Feedback Type: Bug Package: SPL related Operating System: * PHP Version: 5.3.0 New Comment: Hello, Have exactly the same problem with Zend Framework + Doctrine (they both register own autoloaders). So when APC is enabled - it reproduces same fatal error. I'll try to gather more information about what happens little bit later. My PHP version is 5.3.2 Previous Comments: [2010-03-09 08:30:14] travisghansen at yahoo dot com After many hours I finally found this bug report and I am experiencing this same issue. With a little guidance (I don't claim to be an expert) I'd be happy to provide a self contained script. [2010-02-19 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2010-02-11 13:55:47] tomas dot plesek at gmail dot com Ok, I will provide test suite some time later in the evening, as this issue is not easily demonstrated. [2010-02-11 10:58:35] paj...@php.net Can you please provid a small reproduce script, self contained, so we can run a diagnostic and try to fix this issue. Please post this script here, this bug report seems to be valid but the infos are splitted between blog posts, external forums and extensive explanations, that does not help. [2010-02-11 10:41:12] nicolas dot lepage at yahoo dot fr Reopening The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49867 -- Edit this bug report at http://bugs.php.net/bug.php?id=49867&edit=1
Bug #49867 [Com]: spl_autoload crashes when called in write function of custom sessionSaveHandler
Edit report at http://bugs.php.net/bug.php?id=49867&edit=1 ID: 49867 Comment by: zapparov at member dot fsf dot org Reported by: nicolas dot lepage at yahoo dot fr Summary: spl_autoload crashes when called in write function of custom sessionSaveHandler Status: No Feedback Type: Bug Package: SPL related Operating System: * PHP Version: 5.3.0 New Comment: Forgot to say - error occurs wonly when APC is enabled. Previous Comments: [2010-06-12 11:24:11] zapparov at member dot fsf dot org Hello, Have exactly the same problem with Zend Framework + Doctrine (they both register own autoloaders). So when APC is enabled - it reproduces same fatal error. I'll try to gather more information about what happens little bit later. My PHP version is 5.3.2 [2010-03-09 08:30:14] travisghansen at yahoo dot com After many hours I finally found this bug report and I am experiencing this same issue. With a little guidance (I don't claim to be an expert) I'd be happy to provide a self contained script. [2010-02-19 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2010-02-11 13:55:47] tomas dot plesek at gmail dot com Ok, I will provide test suite some time later in the evening, as this issue is not easily demonstrated. [2010-02-11 10:58:35] paj...@php.net Can you please provid a small reproduce script, self contained, so we can run a diagnostic and try to fix this issue. Please post this script here, this bug report seems to be valid but the infos are splitted between blog posts, external forums and extensive explanations, that does not help. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49867 -- Edit this bug report at http://bugs.php.net/bug.php?id=49867&edit=1
[PHP-BUG] Bug #52063 [NEW]: DateTime constructor's second argument doesn't have a null default value
From: cataphract
Operating system: Irrelevant
PHP version: 5.3.2
Package: Date/time related
Bug Type: Bug
Bug description:DateTime constructor's second argument doesn't have a null
default value
Description:
DateTime's constructor is documented like this:
public DateTime::__construct ([ string $time = "now" [, DateTimeZone
$timezone = NULL ]] )
However, not passing the constructor the second argument is not the same as
passing NULL. Fixing this is just a matter of adding a "!", like this
if (SUCCESS == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|sO",
&time_str, &time_str_len, &timezone_object, date_ce_timezone)) {
into
if (SUCCESS == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|sO!",
&time_str, &time_str_len, &timezone_object, date_ce_timezone)) {
Test script:
---
format(DateTime::COOKIE);
Expected result:
Thursday, 01-Jan-09 00:00:00 WET
Actual result:
--
Fatal error: Uncaught exception 'Exception' with message
'DateTime::__construct() expects parameter 2 to be DateTimeZone, null
given' in /tmp/cpCZPA42:4 Stack trace: #0 /tmp/cpCZPA42(4):
DateTime->__construct('2009-01-01', NULL) #1 {main} thrown in /tmp/cpCZPA42
on line 4
--
Edit bug report at http://bugs.php.net/bug.php?id=52063&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52063&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52063&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52063&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52063&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52063&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52063&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52063&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52063&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52063&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52063&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52063&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52063&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52063&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52063&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52063&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52063&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52063&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52063&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52063&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52063&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52063&r=mysqlcfg
[PHP-BUG] Bug #52064 [NEW]: while loop does not meet conditions
From:
Operating system: FreeBSD
PHP version: 5.3.2
Package: *General Issues
Bug Type: Bug
Bug description:while loop does not meet conditions
Description:
I am seeing a bug in PHP 5.3 where the WHILE LOOP is not meeting all of the
conditions. The same code was working great in PHP 5.2 but broke after a
PHP upgrade. I reviewed the PHP 5.3 change-log and nothing is mentioned for
changes in WHILE LOOP conditions.
Test script:
---
0)) {
$rlength--;
}
if ($rlength== 0) {
return substr($string, 0, $setlength);
} else {
return substr($string, 0, $rlength).'.';
}
}else {
return $string;
}
}
$mstr = 'ProNeticas has released a visual rapid database design tool. This
allows you to generate online programs in rapid time, without any
programming.';
print cutTextPer( (String)$mstr, 52);
?>
[OUTPUT IN PHP 5.2]
ProNeticas has released a visual rapid database design tool.
[OUTPUT IN PHP 5.3]
ProNeticas has released a visual rapid database de
Expected result:
ProNeticas has released a visual rapid database design tool.
Actual result:
--
ProNeticas has released a visual rapid database de
--
Edit bug report at http://bugs.php.net/bug.php?id=52064&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52064&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52064&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52064&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52064&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52064&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52064&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52064&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52064&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52064&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52064&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52064&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52064&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52064&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52064&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52064&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52064&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52064&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52064&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52064&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52064&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52064&r=mysqlcfg
Bug #25132 [Com]: if compiled with --enable-gd-native-ttf images with ->accents show font errors
Edit report at http://bugs.php.net/bug.php?id=25132&edit=1
ID: 25132
Comment by: f at endeer dot cz
Reported by: mail_fidel at yahoo dot com
Summary: if compiled with --enable-gd-native-ttf images with
->accents show font errors
Status: No Feedback
Type: Bug
Package: GD related
Operating System: FreeBSD 4.7
PHP Version: 4.3.3RC2
Assigned To: pajoye
New Comment:
The problem with accents has been reintroduced, but this time it's not
--enable-gd-native-ttf, but --enable-gd-jis-conv which is causing this.
Verified on PHP 5.2.13.
Previous Comments:
[2009-11-11 10:27:33] itsme at tomkiss dot net
Just to report - I have also experienced this problem on varying
versions of PHP (5.2.6 on MAMP on Mac and 5.2.11 on CentOS).
The example script on PHP.net for imagettftext produced the same result
listed here previously = Accents and extended character sets (Polish for
example) are all missed out or some characters displayed incorrectly
when --enable-gd-native-ttf is enabled in the PHP compile.
Would be nice to fix this, looks like it's been around a while!
[2003-08-26 00:59:27] sni...@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2003-08-21 06:33:40] paj...@php.net
Can you try this simple script instead?
$im = imagecreatetruecolor(200,200);
$black = imagecolorallocate($im, 255,0,0);
imagettftext($im, 20, 0, 10, 20, $black, "arial.ttf",
"buen día");
imagepng($im, 'res.png');
On which platform do you work?
pierre
[2003-08-19 10:27:01] mail_fidel at yahoo dot com
This are the config options:
Configure Command => './configure' '--enable-versioning'
'--enable-memory-limit' '--with-layout=GNU' '--with-zlib-dir=/usr'
'--disable-a
ll' '--with-regex=php' '--enable-discard-path' '--enable-bcmath'
'--enable-ctype' '--with-dom=/usr/local' '--with-dom-xslt=/usr/local'
'-
-with-dom-exslt=/usr/local' '--enable-filepro' '--with-gd'
'--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local'
'--with-png-dir=
/usr/local' '--with-xpm-dir=/usr/local' '--with-imap=/usr/local'
'--with-imap-ssl=/usr/local' '--enable-mbstring' '--enable-mbregex'
'--w
ith-mysql=/usr/local' '--enable-overload' '--with-pcre-regex=yes'
'--enable-posix' '--with-readline' '--enable-session' '--enable-tokeniz
er' '--enable-xml' '--with-expat-dir=/usr/local' '--with-zlib=yes'
'--prefix=/usr/local' 'i386-portbld-freebsd4.7'
This is my working built, without --enable-gd-native-ttf
Freetype version:
freetype2-2.1.4_1
Example code:
function getImage($font,$string,$point,$color,$bgcolor)
{
$ses = session_id();
$fileName = $ses."_.png";
$measures = imagettfbbox ( $point, "0", $this->fonts_path.$font,
$string);
$width = abs($measures[4] - $measures[0])+20;
$upper = abs($measures[5])+5;
$under = abs($measures[1])+5;
$height = $upper + $under;
$image = imagecreate($width, $height);
//Allocate some colors.
$color = eregi_replace("#","",$color);
$ri = hexdec(substr($color, 0, 2));
$gi = hexdec(substr($color, 2, 2));
$bi = hexdec(substr($color, 4, 2));
$bgcolor = eregi_replace("#","",$bgcolor);
$rb = hexdec(substr($bgcolor, 0, 2));
$gb = hexdec(substr($bgcolor, 2, 2));
$bb = hexdec(substr($bgcolor, 4, 2));
$bg_color = imagecolorallocate($image,$rb ,$gb,$bb);
$typeface_color = imagecolorallocate($image, $ri, $gi, $bi);
imagecolortransparent($image,$bg_color);
imagefilledrectangle($image, 0, 0, $width, $height, $bg_color);
imagettftext($image, $point, 0, 10, $upper+2,
$typeface_color,$this->fonts_path.$font, $string);
$path = $this->temp_path;
imagepng($image,$path.$fileName);
//Finally, free up the memory allocated for the image.
imagedestroy($image);
return($fileName);
}
when trying to solve the problem we change the image type from png to
gif to jpg to see if this was the problem. We upgrade freetype and GD.
Then I read that php 4.3.3 was using some "recomended" native gd code
and when I saw the --enable-gd-native-ttf I decided to turned off and
the scripts start working again.
I'm sure is not a font related problem, first because it worked just
before the update, and second bacause we have a big library of ttf fonts
and we test it with all of them (since some fonts do not
[PHP-BUG] Bug #52065 [NEW]: Warning about open_basedir restriction while accessing a file as directory
From:
Operating system: Unix
PHP version: 5.3SVN-2010-06-12 (SVN)
Package: Safe Mode/open_basedir
Bug Type: Bug
Bug description:Warning about open_basedir restriction while accessing a file
as directory
Description:
fopen_wrappers raise warning about open_basedir restriction in effect while
accessing a file as a directory. This only occurs if the file exists.
Test script:
---
# sapi/cli/php -n -d open_basedir="$(pwd)" -r
'var_dump(is_readable("myfile/doesntexist"));'
# touch myfile
# sapi/cli/php -n -d open_basedir="$(pwd)" -r
'var_dump(is_readable("myfile/doesntexist"));'
Expected result:
bool(false)
bool(false)
Actual result:
--
bool(false)
Warning: is_readable(): open_basedir restriction in effect.
File(myfile/doesntexist) is not within the allowed path(s):
(/home/manuel/php5.3-201006120030) in Command line code on line 1
bool(false)
--
Edit bug report at http://bugs.php.net/bug.php?id=52065&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52065&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52065&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52065&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52065&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52065&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52065&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52065&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52065&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52065&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52065&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52065&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52065&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52065&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52065&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52065&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52065&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52065&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52065&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52065&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52065&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52065&r=mysqlcfg
Bug #52062 [Opn->Asn]: large timestamps with DateTime::getTimestamp and DateTime::setTimestamp
Edit report at http://bugs.php.net/bug.php?id=52062&edit=1
ID: 52062
Updated by: fel...@php.net
Reported by: dan at bnet dot lt
Summary: large timestamps with DateTime::getTimestamp and
DateTime::setTimestamp
-Status: Open
+Status: Assigned
Type: Bug
Package: Date/time related
Operating System: Ubuntu i686 2.6.32-22-generic
PHP Version: 5.3.2
-Assigned To:
+Assigned To: derick
Previous Comments:
[2010-06-12 05:15:09] dan at bnet dot lt
Description:
DateTime::getTimestamp(), DateTime::setTimestamp() and DateInterval does
not work
with large timestamps (using numbers over x86 integers)
Test script:
---
$d = new DateTime('@1000');
var_dump($d->format('Y-m-d H:i:s U'));
var_dump($d->getTimestamp());
$d->setTimestamp(1000);
var_dump($d->format('Y-m-d H:i:s U'));
var_dump($d->getTimestamp());
$i = new DateInterval('PT1000S');
var_dump($i->format('%s'));
Expected result:
string(32) "5138-11-16 09:46:40 1000"
float(1000)
string(32) "5138-11-16 09:46:40 1000"
float(1000)
string(12) "1000"
Actual result:
--
string(32) "5138-11-16 09:46:40 1000"
bool(false)
string(30) "2008-07-11 04:56:32 1215752192"
int(1215752192)
Exception with message 'DateInterval::__construct(): Unknown or bad
format
(PT1000S)'
--
Edit this bug report at http://bugs.php.net/bug.php?id=52062&edit=1
Bug #52063 [Opn->Asn]: DateTime constructor's second argument doesn't have a null default value
Edit report at http://bugs.php.net/bug.php?id=52063&edit=1
ID: 52063
Updated by: fel...@php.net
Reported by: cataphr...@php.net
Summary: DateTime constructor's second argument doesn't have a
null default value
-Status: Open
+Status: Assigned
Type: Bug
Package: Date/time related
Operating System: Irrelevant
PHP Version: 5.3.2
-Assigned To:
+Assigned To: derick
Previous Comments:
[2010-06-12 12:29:03] cataphr...@php.net
Description:
DateTime's constructor is documented like this:
public DateTime::__construct ([ string $time = "now" [, DateTimeZone
$timezone = NULL ]] )
However, not passing the constructor the second argument is not the same
as passing NULL. Fixing this is just a matter of adding a "!", like
this
if (SUCCESS == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|sO",
&time_str, &time_str_len, &timezone_object, date_ce_timezone)) {
into
if (SUCCESS == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|sO!",
&time_str, &time_str_len, &timezone_object, date_ce_timezone)) {
Test script:
---
format(DateTime::COOKIE);
Expected result:
Thursday, 01-Jan-09 00:00:00 WET
Actual result:
--
Fatal error: Uncaught exception 'Exception' with message
'DateTime::__construct() expects parameter 2 to be DateTimeZone, null
given' in /tmp/cpCZPA42:4 Stack trace: #0 /tmp/cpCZPA42(4):
DateTime->__construct('2009-01-01', NULL) #1 {main} thrown in
/tmp/cpCZPA42 on line 4
--
Edit this bug report at http://bugs.php.net/bug.php?id=52063&edit=1
Bug #52054 [Opn->Bgs]: Class 'PDO' not found
Edit report at http://bugs.php.net/bug.php?id=52054&edit=1 ID: 52054 Updated by: fel...@php.net Reported by: deuce at gt dot rr dot com Summary: Class 'PDO' not found -Status: Open +Status: Bogus Type: Bug Package: PDO related Operating System: linux kernel 2.6.27-grsec4 PHP Version: 5.2.13 New Comment: I got the message: "could not find driver"... PDO seems not be enabled in your instalation. Previous Comments: [2010-06-11 20:31:49] deuce at gt dot rr dot com Description: When a specific database module is not installed and a PDO object of this type is called you receive an error reporting that PDO does not exist. Test script: --- getMessage()} \n"; exit; } ?> Expected result: Failed to get DB handle: could not find driver Failed to get DB handle: could not find module etc. Actual result: -- PHP Fatal error: Class 'PDO' not found in /home/../login.php on line 10 -- Edit this bug report at http://bugs.php.net/bug.php?id=52054&edit=1
Bug #49867 [NoF]: spl_autoload crashes when called in write function of custom sessionSaveHandler
Edit report at http://bugs.php.net/bug.php?id=49867&edit=1 ID: 49867 Updated by: ras...@php.net Reported by: nicolas dot lepage at yahoo dot fr Summary: spl_autoload crashes when called in write function of custom sessionSaveHandler Status: No Feedback Type: Bug Package: SPL related Operating System: * PHP Version: 5.3.0 New Comment: Doesn't calling session_write_close() completely solve this issue? Previous Comments: [2010-06-12 12:23:24] zapparov at member dot fsf dot org Forgot to say - error occurs wonly when APC is enabled. [2010-06-12 11:24:11] zapparov at member dot fsf dot org Hello, Have exactly the same problem with Zend Framework + Doctrine (they both register own autoloaders). So when APC is enabled - it reproduces same fatal error. I'll try to gather more information about what happens little bit later. My PHP version is 5.3.2 [2010-03-09 08:30:14] travisghansen at yahoo dot com After many hours I finally found this bug report and I am experiencing this same issue. With a little guidance (I don't claim to be an expert) I'd be happy to provide a self contained script. [2010-02-19 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2010-02-11 13:55:47] tomas dot plesek at gmail dot com Ok, I will provide test suite some time later in the evening, as this issue is not easily demonstrated. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49867 -- Edit this bug report at http://bugs.php.net/bug.php?id=49867&edit=1
Bug #52054 [Bgs]: Class 'PDO' not found
Edit report at http://bugs.php.net/bug.php?id=52054&edit=1
ID: 52054
User updated by: deuce at gt dot rr dot com
Reported by: deuce at gt dot rr dot com
Summary: Class 'PDO' not found
Status: Bogus
Type: Bug
Package: PDO related
Operating System: linux kernel 2.6.27-grsec4
PHP Version: 5.2.13
New Comment:
If you change the value to a module that is loaded on the server, in
this case
mysql, it goes through as expected.
$dbh = new PDO ("mysql:host={$hostname};dbname={$dbname}", $username,
$pw);
works just fine.
I do not have direct control of these machines, and at this point I
believe it
was a default server configuration error which the host has now
corrected. That
is all I know, if you wish to try and figure out as to why or how
contacting
site5 LLC would be the quickest solution. Beau and/or Graham are two
higher ups
that are familiar with the issue.
Previous Comments:
[2010-06-12 15:14:30] fel...@php.net
I got the message: "could not find driver"... PDO seems not be enabled
in your instalation.
[2010-06-11 20:31:49] deuce at gt dot rr dot com
Description:
When a specific database module is not installed and a PDO object of
this type is
called you receive an error reporting that PDO does not exist.
Test script:
---
getMessage()} \n";
exit;
}
?>
Expected result:
Failed to get DB handle: could not find driver
Failed to get DB handle: could not find module
etc.
Actual result:
--
PHP Fatal error: Class 'PDO' not found in /home/../login.php on line 10
--
Edit this bug report at http://bugs.php.net/bug.php?id=52054&edit=1
Bug #52051 [Opn->Asn]: handling of case sensitivity of old-style constructors changed in 5.3+
Edit report at http://bugs.php.net/bug.php?id=52051&edit=1 ID: 52051 Updated by: fel...@php.net Reported by: php at kingsquare dot nl Summary: handling of case sensitivity of old-style constructors changed in 5.3+ -Status: Open +Status: Assigned Type: Bug Package: Scripting Engine problem Operating System: Win32 PHP Version: 5.3.2 -Assigned To: +Assigned To: felipe Previous Comments: [2010-06-11 17:33:10] php at kingsquare dot nl Description: Since PHP 5.3+ (it worked in 5.2.6) handling of old-style constructors with case sensitive (i.e. camelcasing) changed. The 'generated' constructor is only available in lower case since 5.3 Test script: --- C() C:\php\test.php:20 -- Edit this bug report at http://bugs.php.net/bug.php?id=52051&edit=1
Bug #52051 [Asn->Csd]: handling of case sensitivity of old-style constructors changed in 5.3+
Edit report at http://bugs.php.net/bug.php?id=52051&edit=1 ID: 52051 Updated by: fel...@php.net Reported by: php at kingsquare dot nl Summary: handling of case sensitivity of old-style constructors changed in 5.3+ -Status: Assigned +Status: Closed Type: Bug Package: Scripting Engine problem Operating System: Win32 PHP Version: 5.3.2 Assigned To: felipe New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-06-12 17:30:23] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=300407 Log: - Fixed bug #52051 (handling of case sensitivity of old-style constructors changed in 5.3+) [2010-06-11 17:33:10] php at kingsquare dot nl Description: Since PHP 5.3+ (it worked in 5.2.6) handling of old-style constructors with case sensitive (i.e. camelcasing) changed. The 'generated' constructor is only available in lower case since 5.3 Test script: --- C() C:\php\test.php:20 -- Edit this bug report at http://bugs.php.net/bug.php?id=52051&edit=1
Bug #52064 [Opn->Fbk]: while loop does not meet conditions
Edit report at http://bugs.php.net/bug.php?id=52064&edit=1
ID: 52064
Updated by: fel...@php.net
Reported by: developers at proneticas dot net
Summary: while loop does not meet conditions
-Status: Open
+Status: Feedback
Type: Bug
Package: *General Issues
Operating System: FreeBSD
PHP Version: 5.3.2
New Comment:
Which 5.2 release are you refering to?
Previous Comments:
[2010-06-12 12:51:58] developers at proneticas dot net
Description:
I am seeing a bug in PHP 5.3 where the WHILE LOOP is not meeting all of
the conditions. The same code was working great in PHP 5.2 but broke
after a PHP upgrade. I reviewed the PHP 5.3 change-log and nothing is
mentioned for changes in WHILE LOOP conditions.
Test script:
---
0)) {
$rlength--;
}
if ($rlength== 0) {
return substr($string, 0, $setlength);
} else {
return substr($string, 0, $rlength).'.';
}
}else {
return $string;
}
}
$mstr = 'ProNeticas has released a visual rapid database design tool.
This allows you to generate online programs in rapid time, without any
programming.';
print cutTextPer( (String)$mstr, 52);
?>
[OUTPUT IN PHP 5.2]
ProNeticas has released a visual rapid database design tool.
[OUTPUT IN PHP 5.3]
ProNeticas has released a visual rapid database de
Expected result:
ProNeticas has released a visual rapid database design tool.
Actual result:
--
ProNeticas has released a visual rapid database de
--
Edit this bug report at http://bugs.php.net/bug.php?id=52064&edit=1
Bug #52049 [Opn->Bgs]: crash when verifying gnupg signature
Edit report at http://bugs.php.net/bug.php?id=52049&edit=1
ID: 52049
Updated by: paj...@php.net
Reported by: viktors at ok dot lv
Summary: crash when verifying gnupg signature
-Status: Open
+Status: Bogus
Type: Bug
Package: Unknown/Other Function
Operating System: ubuntu linux
PHP Version: 5.3.2
New Comment:
Please report Gnupg bugs to the pecl bugs report
(http://pecl.php.net/gnupg)
Previous Comments:
[2010-06-11 14:11:51] viktors at ok dot lv
Description:
Ubuntu 10.04 amd64. 100% reproducable on version 5.3.2-1ubuntu4.2 and
5.2.10.dfsg.1-2ubuntu6.4.
On version 5.2.6.dfsg.1-3ubuntu4.5 works fine!
GnuPG extension installed with "pecl install gnupg".
Key import works fine, but signature verification on valid pgp file
crashes php.
Any ideas how to further debug and find out whats the reason for crash?
Thank you!
# cat cc.php
verify(file_get_contents('valid.gpg'), false, $plaintext);
?>
# gdb php5
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
Req #52052 [PATCH]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 Patch added by: f...@php.net Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: The following patch has been added/updated: Patch Name: fpm-syslog.v1.patch Revision: 1276361235 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v1.patch&revision=1276361235 Previous Comments: [2010-06-11 18:10:10] ef-lists at email dot de Description: At current, FPM only allows logging to local files, both for the ErrorLog and SlowLog. Using syslog aids the administrator greatly in centralizing logfiles. Also PHP itself has syslog support, so FPM should consequently have it, too. I hereby ask to add syslog support to FPM. -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Req #52052 [Com]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 Comment by: f...@php.net Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: The attached patch should activate syslog sypport to error_log only. You can try it on trunk. change error_log to "syslog" You can also set syslog_facility and syslog_ident to feet your needs. But default values should be OK. I'm working on the slowlog patch also but it's a bit more complicated. ++ Jerome Previous Comments: [2010-06-12 18:47:15] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v1.patch Revision: 1276361235 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v1.patch&revision=1276361235 [2010-06-11 18:10:10] ef-lists at email dot de Description: At current, FPM only allows logging to local files, both for the ErrorLog and SlowLog. Using syslog aids the administrator greatly in centralizing logfiles. Also PHP itself has syslog support, so FPM should consequently have it, too. I hereby ask to add syslog support to FPM. -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Bug #51430 [Opn]: Numeric string array key is being implicitly cast to 32bit int and overflowing
Edit report at http://bugs.php.net/bug.php?id=51430&edit=1
ID: 51430
Updated by: paj...@php.net
Reported by: will at flourishlib dot com
Summary: Numeric string array key is being implicitly cast to
32bit int and overflowing
Status: Open
Type: Bug
Package: Scripting Engine problem
Operating System: Fedora 12
PHP Version: 5.3.2
New Comment:
@colder I don't think we ever supported 64bit numeric on 32bit
platforms.
Previous Comments:
[2010-06-11 15:52:36] will at flourishlib dot com
Here is the info from the original 32bit machine that also sees the bug
in
5.3.3-dev:
# ./php -v
PHP 5.3.3-dev (cli) (built: Jun 11 2010 09:48:12)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
# ./php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
# uname -a
Linux vm-fedora 2.6.31.12-174.2.22.fc12.i686.PAE #1 SMP Fri Feb 19
19:10:04 UTC
2010 i686 i686 i386 GNU/Linux
# gcc -v
Using built-in specs.
Target: i686-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --
enable-bootstrap --enable-shared --enable-threads=posix --enable-
checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-
exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-
c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi
--enable-plugin --
with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile
--enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --
disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic
--with-
arch=i686 --build=i686-redhat-linux
Thread model: posix
gcc version 4.4.3 20100127 (Red Hat 4.4.3-4) (GCC)
[2010-06-11 15:35:56] will at flourishlib dot com
Both 5.3.3-dev and trunk were built on the following machine:
# uname -a
Linux vm-opensuse 2.6.31.12-0.1-desktop #1 SMP PREEMPT 2010-01-27
08:20:11 +0100 i686 i686 i386 GNU/Linux
# gcc -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib
--libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-
gxx-include-dir=/usr/include/c++/4.4 --enable-ssp --disable-libssp
--with-bugurl=http://bugs.opensuse.org/ --
with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib --with-system-zlib --
enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-
libs --program-suffix=-4.4 --enable-linux-futex
--without-system-libunwind --with-arch-32=i586 --with-
tune=generic --build=i586-suse-linux
Thread model: posix
gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux)
[2010-06-11 15:27:41] col...@php.net
Apparently it's still reproducible in some environments with the latest
5.3
snapshot, Not on mine though.
[2010-06-11 15:24:50] will at flourishlib dot com
I just built php-trunk and got the same bug:
# wget http://snaps.php.net/php-trunk-201006111230.tar.bz2
# tar xvfj php-trunk-201006111230.tar.bz2
# cd php-trunk-201006111230/
# ./configure
# make
# cd sapi/cli/
# ./php -v
PHP 5.3.99-dev (cli) (built: Jun 11 2010 09:19:41)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2010 Zend Technologies
# ./php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
This is on a 32bit OpenSUSE machine:
# uname -a
Linux vm-opensuse 2.6.31.12-0.1-desktop #1 SMP PREEMPT 2010-01-27
08:20:11 +0100
i686 i686 i386 GNU/Linux
[2010-06-11 15:05:45] will at flourishlib dot com
I just built 5.3.3-dev and I am still having the same bug:
# wget http://snaps.php.net/php5.3-201006111230.tar.bz2
# tar xvfj php5.3-201006111230.tar.bz2
# cd php5.3-201006111230/
# ./configure
# make
# cd sapi/cli/
# ./php -v
PHP 5.3.3-dev (cli) (built: Jun 11 2010 08:57:11)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
# ./php -r 'print_r(array("-2147483649" => TRUE, "-2147483648" =>
FALSE));'
Array
(
[2147483647] => 1
[-2147483648] =>
)
The remainder of the comments for this
Bug #52049 [Bgs]: crash when verifying gnupg signature
Edit report at http://bugs.php.net/bug.php?id=52049&edit=1
ID: 52049
User updated by: viktors at ok dot lv
Reported by: viktors at ok dot lv
Summary: crash when verifying gnupg signature
Status: Bogus
Type: Bug
Package: Unknown/Other Function
Operating System: ubuntu linux
PHP Version: 5.3.2
New Comment:
Is this really a gnupg extensions bug not php?
1) GnuPG pecl extension hasn't changed for years, all that changed is
PHP.
2) If the bug is in extension why does PHP segfaults in cryptic
zend_do_fcall_common_helper_SPEC()?
Is there a way to track down bug to get more hints whats the reason for
it?
Thank you!
Previous Comments:
[2010-06-12 18:45:28] paj...@php.net
Please report Gnupg bugs to the pecl bugs report
(http://pecl.php.net/gnupg)
[2010-06-11 14:11:51] viktors at ok dot lv
Description:
Ubuntu 10.04 amd64. 100% reproducable on version 5.3.2-1ubuntu4.2 and
5.2.10.dfsg.1-2ubuntu6.4.
On version 5.2.6.dfsg.1-3ubuntu4.5 works fine!
GnuPG extension installed with "pecl install gnupg".
Key import works fine, but signature verification on valid pgp file
crashes php.
Any ideas how to further debug and find out whats the reason for crash?
Thank you!
# cat cc.php
verify(file_get_contents('valid.gpg'), false, $plaintext);
?>
# gdb php5
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
Bug #50374 [NoF->Asn]: .user.ini subdirectory not working and problem with [PATH] in php.ini
Edit report at http://bugs.php.net/bug.php?id=50374&edit=1 ID: 50374 Updated by: paj...@php.net Reported by: tom_borgo at hotmail dot com Summary: .user.ini subdirectory not working and problem with [PATH] in php.ini -Status: No Feedback +Status: Assigned Type: Bug Package: Scripting Engine problem Operating System: XP SP3 PHP Version: 5.3.1 Assigned To: pajoye Previous Comments: [2010-06-10 21:15:49] jirka at pbox dot cz Same issue with php 5.3.2 (CGI) on WinXP SP3. Build date Apr 1 2010 17:13:20. .user.ini custom setting works in the directory where the ini file is located, but has no effect in any of subdirectories. [2009-12-11 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-12-03 16:10:27] tom_borgo at hotmail dot com Ok so i just tried with the 5.3.2-dev (Dec 3 2009 14:57:19) snapshot. Problem .user.ini for php script in subdirectory is always the same. /www/phpinfo.php -> take into account the /www/.user.ini /www/administrator/phpinfo.php -> take NOT into account the /www/.user.ini For the [PATH] problem, i tried and problem is no more here. So I tried again with 5.3.1, no more problem. Problem is just with 5.3.0 (VC8 from ZendServer), so [PATH] problem is just for ZendServer. So we can forgot about the [PATH] problem. But for the .user.ini, am i mistaken something ? Or is it a php problem ? Thanks. Thomas. [2009-12-03 15:50:05] tom_borgo at hotmail dot com To: paj...@php.net Yes I know it works only for CGI/FastCGI SAPI (http://php.net/manual/en/configuration.file.per-user.php). .user.ini works for me only for the directory where it is and without any [PATH] section in the main php.ini. I tried with a PHP downloaded from the php.net (5.3.1 NTS VC6 and i try with VC9 too). It is the same as the one from ZendServer (VC8). So problem is in ZendServer,but too in the last stable binary windows compiled on the php.net website. Is it a configuration problem on my side or does another people got the same problems ? I will try with the snapshot right now. I keep you warning. Thanks. Thomas. [2009-12-03 15:39:18] tom_borgo at hotmail dot com Just a comment about the [PATH] section It is said in http://php.net/ini.sections that directive in PATH section overide custom and runtime ini directives. So I think it is in fact normal that .user.ini don't change the display_errors flag. But .user.ini are not parsed if [PATH] section are in the main php.ini for other directory Ex: [PATH=/www2/] display_errors = 1 /www/.user.ini is not more taken into account ! If i remove the PATH section (i put it inthe end of my php.ini), .user.ini is taken into account. Really strange... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=50374 -- Edit this bug report at http://bugs.php.net/bug.php?id=50374&edit=1
[PHP-BUG] Bug #52067 [NEW]: chdir to a nonexisting directory when chrooting is buggy
From: fat Operating system: linux PHP version: 5.3SVN-2010-06-12 (SVN) Package: FPM related Bug Type: Bug Bug description:chdir to a nonexisting directory when chrooting is buggy Description: when setting chroot and chdir to a non existing directory into the chroot. FPM loops creating children which are dying because they can't chdir. Jun 12 19:46:10.884803 [NOTICE] [pool www] child 27114 started Jun 12 19:46:10.884930 [WARNING] [pool www] child 27114 exited with code 255 after 0.000149 seconds from start Jun 12 19:46:10.885001 [WARNING] [pool www] child 27114 said into stderr: "Jun 12 19:46:10.884025 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.885072 [WARNING] [pool www] child 27114 said into stderr: "Jun 12 19:46:10.884153 [ERROR] [pool www] child failed to initialize", pipe is closed Jun 12 19:46:10.886642 [NOTICE] [pool www] child 27115 started Jun 12 19:46:10.886768 [WARNING] [pool www] child 27115 exited with code 255 after 0.000149 seconds from start Jun 12 19:46:10.886842 [WARNING] [pool www] child 27115 said into stderr: "Jun 12 19:46:10.885852 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.886914 [WARNING] [pool www] child 27115 said into stderr: "Jun 12 19:46:10.885982 [ERROR] [pool www] child failed to initialize", pipe is closed Jun 12 19:46:10.888469 [NOTICE] [pool www] child 27116 started Jun 12 19:46:10.888596 [WARNING] [pool www] child 27116 exited with code 255 after 0.000150 seconds from start Jun 12 19:46:10.888671 [WARNING] [pool www] child 27116 said into stderr: "Jun 12 19:46:10.887691 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.888744 [WARNING] [pool www] child 27116 said into stderr: "Jun 12 19:46:10.887820 [ERROR] [pool www] child failed to initialize", pipe is closed Jun 12 19:46:10.890295 [NOTICE] [pool www] child 27117 started Jun 12 19:46:10.890422 [WARNING] [pool www] child 27117 exited with code 255 after 0.000150 seconds from start Jun 12 19:46:10.890491 [WARNING] [pool www] child 27117 said into stderr: "Jun 12 19:46:10.889524 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.890563 [WARNING] [pool www] child 27117 said into stderr: "Jun 12 19:46:10.889651 [ERROR] [pool www] child failed to initialize", pipe is closed Jun 12 19:46:10.893124 [NOTICE] [pool www] child 27119 started Jun 12 19:46:10.893256 [WARNING] [pool www] child 27119 exited with code 255 after 0.000155 seconds from start Jun 12 19:46:10.893329 [WARNING] [pool www] child 27119 said into stderr: "Jun 12 19:46:10.892335 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.893401 [WARNING] [pool www] child 27119 said into stderr: "Jun 12 19:46:10.892467 [ERROR] [pool www] child failed to initialize", pipe is closed Test script: --- chroot=/usr/local/nginx/html chdir=/usr/local/nginx/html -- Edit bug report at http://bugs.php.net/bug.php?id=52067&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52067&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52067&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52067&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52067&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52067&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52067&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52067&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52067&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52067&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52067&r=support Expected behavior: http://bugs.php.net/fix.php?id=52067&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52067&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52067&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52067&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52067&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52067&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52067&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52067&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52067&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52067&r=nozend MySQL Configuration Error: http:
Bug #52067 [Opn->Asn]: chdir to a nonexisting directory when chrooting is buggy
Edit report at http://bugs.php.net/bug.php?id=52067&edit=1 ID: 52067 Updated by: f...@php.net Reported by: f...@php.net Summary: chdir to a nonexisting directory when chrooting is buggy -Status: Open +Status: Assigned Type: Bug Package: FPM related Operating System: linux PHP Version: 5.3SVN-2010-06-12 (SVN) -Assigned To: +Assigned To: fat Previous Comments: [2010-06-12 19:49:58] f...@php.net Description: when setting chroot and chdir to a non existing directory into the chroot. FPM loops creating children which are dying because they can't chdir. Jun 12 19:46:10.884803 [NOTICE] [pool www] child 27114 started Jun 12 19:46:10.884930 [WARNING] [pool www] child 27114 exited with code 255 after 0.000149 seconds from start Jun 12 19:46:10.885001 [WARNING] [pool www] child 27114 said into stderr: "Jun 12 19:46:10.884025 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.885072 [WARNING] [pool www] child 27114 said into stderr: "Jun 12 19:46:10.884153 [ERROR] [pool www] child failed to initialize", pipe is closed Jun 12 19:46:10.886642 [NOTICE] [pool www] child 27115 started Jun 12 19:46:10.886768 [WARNING] [pool www] child 27115 exited with code 255 after 0.000149 seconds from start Jun 12 19:46:10.886842 [WARNING] [pool www] child 27115 said into stderr: "Jun 12 19:46:10.885852 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.886914 [WARNING] [pool www] child 27115 said into stderr: "Jun 12 19:46:10.885982 [ERROR] [pool www] child failed to initialize", pipe is closed Jun 12 19:46:10.888469 [NOTICE] [pool www] child 27116 started Jun 12 19:46:10.888596 [WARNING] [pool www] child 27116 exited with code 255 after 0.000150 seconds from start Jun 12 19:46:10.888671 [WARNING] [pool www] child 27116 said into stderr: "Jun 12 19:46:10.887691 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.888744 [WARNING] [pool www] child 27116 said into stderr: "Jun 12 19:46:10.887820 [ERROR] [pool www] child failed to initialize", pipe is closed Jun 12 19:46:10.890295 [NOTICE] [pool www] child 27117 started Jun 12 19:46:10.890422 [WARNING] [pool www] child 27117 exited with code 255 after 0.000150 seconds from start Jun 12 19:46:10.890491 [WARNING] [pool www] child 27117 said into stderr: "Jun 12 19:46:10.889524 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.890563 [WARNING] [pool www] child 27117 said into stderr: "Jun 12 19:46:10.889651 [ERROR] [pool www] child failed to initialize", pipe is closed Jun 12 19:46:10.893124 [NOTICE] [pool www] child 27119 started Jun 12 19:46:10.893256 [WARNING] [pool www] child 27119 exited with code 255 after 0.000155 seconds from start Jun 12 19:46:10.893329 [WARNING] [pool www] child 27119 said into stderr: "Jun 12 19:46:10.892335 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.893401 [WARNING] [pool www] child 27119 said into stderr: "Jun 12 19:46:10.892467 [ERROR] [pool www] child failed to initialize", pipe is closed Test script: --- chroot=/usr/local/nginx/html chdir=/usr/local/nginx/html -- Edit this bug report at http://bugs.php.net/bug.php?id=52067&edit=1
Req #52052 [Asn]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 User updated by: ef-lists at email dot de Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: Great job! :-) I'll try it out and report feedback to you. Previous Comments: [2010-06-12 18:49:35] f...@php.net The attached patch should activate syslog sypport to error_log only. You can try it on trunk. change error_log to "syslog" You can also set syslog_facility and syslog_ident to feet your needs. But default values should be OK. I'm working on the slowlog patch also but it's a bit more complicated. ++ Jerome [2010-06-12 18:47:15] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v1.patch Revision: 1276361235 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v1.patch&revision=1276361235 [2010-06-11 18:10:10] ef-lists at email dot de Description: At current, FPM only allows logging to local files, both for the ErrorLog and SlowLog. Using syslog aids the administrator greatly in centralizing logfiles. Also PHP itself has syslog support, so FPM should consequently have it, too. I hereby ask to add syslog support to FPM. -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
[PHP-BUG] Bug #52068 [NEW]: more closures on script fail
From:
Operating system: Fedora 12, 2.6.32.11-99
PHP version: 5.3.2
Package: *General Issues
Bug Type: Bug
Bug description:more closures on script fail
Description:
I'm not able to use more closures on single script. Closures - assigned to
variable or used as anonymous are null, instead of instance of Closure
class.
Also it is really curious, sometimes it works, if there is more code before
closure creation.
Fedora 12: 2.6.32.12-115.fc12.x86_64
Test script:
---
// * * * * * * * * * * closure 1
echo 'closure 1';
var_dump(function($arg1) {
return intval($arg1) * 2;
});
// * * * * * * * * * * closure 2
echo 'closure 2';
$c2 = function() {
echo time();
};
var_dump($c2);
// * * * * * * * * * * closure 3
echo 'closure 3';
var_dump(function() {
return sha1(strval(rand()));
});
Expected result:
closure 1
object(Closure)[1]
closure 2
object(Closure)[2]
closure 3
object(Closure)[3]
Actual result:
--
closure 1
null
closure 2
null
closure 3
object(Closure)[1]
--
Edit bug report at http://bugs.php.net/bug.php?id=52068&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52068&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52068&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52068&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52068&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52068&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52068&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52068&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52068&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52068&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52068&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52068&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52068&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52068&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52068&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52068&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52068&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52068&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52068&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52068&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52068&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52068&r=mysqlcfg
Bug #52068 [Opn]: more closures on script fail
Edit report at http://bugs.php.net/bug.php?id=52068&edit=1
ID: 52068
Updated by: fel...@php.net
Reported by: wdolek at gmail dot com
Summary: more closures on script fail
Status: Open
Type: Bug
Package: *General Issues
Operating System: Fedora 12, 2.6.32.11-99
PHP Version: 5.3.2
New Comment:
I cannot reproduce it on 5.3.3-dev.
closure 1object(Closure)#1 (1) {
["parameter"]=>
array(1) {
["$arg1"]=>
string(10) ""
}
}
closure 2object(Closure)#1 (0) {
}
closure 3object(Closure)#2 (0) {
}
Previous Comments:
[2010-06-12 21:54:15] wdolek at gmail dot com
Description:
I'm not able to use more closures on single script. Closures - assigned
to variable or used as anonymous are null, instead of instance of
Closure class.
Also it is really curious, sometimes it works, if there is more code
before closure creation.
Fedora 12: 2.6.32.12-115.fc12.x86_64
Test script:
---
// * * * * * * * * * * closure 1
echo 'closure 1';
var_dump(function($arg1) {
return intval($arg1) * 2;
});
// * * * * * * * * * * closure 2
echo 'closure 2';
$c2 = function() {
echo time();
};
var_dump($c2);
// * * * * * * * * * * closure 3
echo 'closure 3';
var_dump(function() {
return sha1(strval(rand()));
});
Expected result:
closure 1
object(Closure)[1]
closure 2
object(Closure)[2]
closure 3
object(Closure)[3]
Actual result:
--
closure 1
null
closure 2
null
closure 3
object(Closure)[1]
--
Edit this bug report at http://bugs.php.net/bug.php?id=52068&edit=1
Bug #52068 [Opn->Fbk]: more closures on script fail
Edit report at http://bugs.php.net/bug.php?id=52068&edit=1
ID: 52068
Updated by: fel...@php.net
Reported by: wdolek at gmail dot com
Summary: more closures on script fail
-Status: Open
+Status: Feedback
Type: Bug
Package: *General Issues
Operating System: Fedora 12, 2.6.32.11-99
PHP Version: 5.3.2
New Comment:
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2010-06-12 22:02:15] fel...@php.net
I cannot reproduce it on 5.3.3-dev.
closure 1object(Closure)#1 (1) {
["parameter"]=>
array(1) {
["$arg1"]=>
string(10) ""
}
}
closure 2object(Closure)#1 (0) {
}
closure 3object(Closure)#2 (0) {
}
[2010-06-12 21:54:15] wdolek at gmail dot com
Description:
I'm not able to use more closures on single script. Closures - assigned
to variable or used as anonymous are null, instead of instance of
Closure class.
Also it is really curious, sometimes it works, if there is more code
before closure creation.
Fedora 12: 2.6.32.12-115.fc12.x86_64
Test script:
---
// * * * * * * * * * * closure 1
echo 'closure 1';
var_dump(function($arg1) {
return intval($arg1) * 2;
});
// * * * * * * * * * * closure 2
echo 'closure 2';
$c2 = function() {
echo time();
};
var_dump($c2);
// * * * * * * * * * * closure 3
echo 'closure 3';
var_dump(function() {
return sha1(strval(rand()));
});
Expected result:
closure 1
object(Closure)[1]
closure 2
object(Closure)[2]
closure 3
object(Closure)[3]
Actual result:
--
closure 1
null
closure 2
null
closure 3
object(Closure)[1]
--
Edit this bug report at http://bugs.php.net/bug.php?id=52068&edit=1
Bug #52068 [Fbk->Csd]: more closures on script fail
Edit report at http://bugs.php.net/bug.php?id=52068&edit=1
ID: 52068
User updated by: wdolek at gmail dot com
Reported by: wdolek at gmail dot com
Summary: more closures on script fail
-Status: Feedback
+Status: Closed
Type: Bug
Package: *General Issues
Operating System: Fedora 12, 2.6.32.11-99
PHP Version: 5.3.2
New Comment:
I have discovered that this is problem of eAccelerator 0.9.6, not
problem of PHP!
Previous Comments:
[2010-06-12 22:02:29] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-06-12 22:02:15] fel...@php.net
I cannot reproduce it on 5.3.3-dev.
closure 1object(Closure)#1 (1) {
["parameter"]=>
array(1) {
["$arg1"]=>
string(10) ""
}
}
closure 2object(Closure)#1 (0) {
}
closure 3object(Closure)#2 (0) {
}
[2010-06-12 21:54:15] wdolek at gmail dot com
Description:
I'm not able to use more closures on single script. Closures - assigned
to variable or used as anonymous are null, instead of instance of
Closure class.
Also it is really curious, sometimes it works, if there is more code
before closure creation.
Fedora 12: 2.6.32.12-115.fc12.x86_64
Test script:
---
// * * * * * * * * * * closure 1
echo 'closure 1';
var_dump(function($arg1) {
return intval($arg1) * 2;
});
// * * * * * * * * * * closure 2
echo 'closure 2';
$c2 = function() {
echo time();
};
var_dump($c2);
// * * * * * * * * * * closure 3
echo 'closure 3';
var_dump(function() {
return sha1(strval(rand()));
});
Expected result:
closure 1
object(Closure)[1]
closure 2
object(Closure)[2]
closure 3
object(Closure)[3]
Actual result:
--
closure 1
null
closure 2
null
closure 3
object(Closure)[1]
--
Edit this bug report at http://bugs.php.net/bug.php?id=52068&edit=1
Bug #52068 [Csd->Bgs]: more closures on script fail
Edit report at http://bugs.php.net/bug.php?id=52068&edit=1
ID: 52068
Updated by: fel...@php.net
Reported by: wdolek at gmail dot com
Summary: more closures on script fail
-Status: Closed
+Status: Bogus
Type: Bug
Package: *General Issues
Operating System: Fedora 12, 2.6.32.11-99
PHP Version: 5.3.2
Previous Comments:
[2010-06-12 22:38:09] wdolek at gmail dot com
I have discovered that this is problem of eAccelerator 0.9.6, not
problem of PHP!
[2010-06-12 22:02:29] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-06-12 22:02:15] fel...@php.net
I cannot reproduce it on 5.3.3-dev.
closure 1object(Closure)#1 (1) {
["parameter"]=>
array(1) {
["$arg1"]=>
string(10) ""
}
}
closure 2object(Closure)#1 (0) {
}
closure 3object(Closure)#2 (0) {
}
[2010-06-12 21:54:15] wdolek at gmail dot com
Description:
I'm not able to use more closures on single script. Closures - assigned
to variable or used as anonymous are null, instead of instance of
Closure class.
Also it is really curious, sometimes it works, if there is more code
before closure creation.
Fedora 12: 2.6.32.12-115.fc12.x86_64
Test script:
---
// * * * * * * * * * * closure 1
echo 'closure 1';
var_dump(function($arg1) {
return intval($arg1) * 2;
});
// * * * * * * * * * * closure 2
echo 'closure 2';
$c2 = function() {
echo time();
};
var_dump($c2);
// * * * * * * * * * * closure 3
echo 'closure 3';
var_dump(function() {
return sha1(strval(rand()));
});
Expected result:
closure 1
object(Closure)[1]
closure 2
object(Closure)[2]
closure 3
object(Closure)[3]
Actual result:
--
closure 1
null
closure 2
null
closure 3
object(Closure)[1]
--
Edit this bug report at http://bugs.php.net/bug.php?id=52068&edit=1
Bug #52043 [Opn->Asn]: GD doesn't recognize latest libJPEG version (8b)
Edit report at http://bugs.php.net/bug.php?id=52043&edit=1 ID: 52043 Updated by: fel...@php.net Reported by: php at group dot apple dot com Summary: GD doesn't recognize latest libJPEG version (8b) -Status: Open +Status: Assigned Type: Bug Package: GD related Operating System: all PHP Version: 5.3.2 -Assigned To: +Assigned To: pajoye Previous Comments: [2010-06-11 03:16:23] php at group dot apple dot com Description: Building php-5.3.2 against libJPEGv8b (NOT 6b!) appears to be functional, but php reports the wrong version number. The patch below adds an additional cast to the switch statement. Test script: --- php -info | grep -i jpeg Expected result: libJPEG Version => 8b Actual result: -- libJPEG Version => unknown -- Edit this bug report at http://bugs.php.net/bug.php?id=52043&edit=1
Bug #52050 [Opn->Asn]: PHP-FPM Dies after self-initiating reload
Edit report at http://bugs.php.net/bug.php?id=52050&edit=1 ID: 52050 Updated by: fel...@php.net Reported by: marcus at adolfsson dot com Summary: PHP-FPM Dies after self-initiating reload -Status: Open +Status: Assigned Type: Bug Package: FPM related Operating System: fc7 PHP Version: 5.3.2 Assigned To: fat Previous Comments: [2010-06-11 16:27:49] marcus at adolfsson dot com ldd /usr/sbin/php-fpm libcrypt.so.1 => /lib64/libcrypt.so.1 (0x003a8300) libaspell.so.15 => /usr/lib64/libaspell.so.15 (0x003a8600) libpspell.so.15 => /usr/lib64/libpspell.so.15 (0x003a8640) librt.so.1 => /lib64/librt.so.1 (0x003a8180) libmysqlclient.so.15 => /usr/lib64/mysql/libmysqlclient.so.15 (0x0036a360) libmcrypt.so.4 => /usr/lib64/libmcrypt.so.4 (0x00357ba0) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0036a320) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0036a3e0) libz.so.1 => /usr/lib64/libz.so.1 (0x0035af40) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x003a8700) libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x0035af80) libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x003a8540) libpcre.so.0 => /lib64/libpcre.so.0 (0x0035b040) libm.so.6 => /lib64/libm.so.6 (0x003a80c0) libdl.so.2 => /lib64/libdl.so.2 (0x003a8080) libevent-1.4.so.1 => /usr/local/lib/libevent-1.4.so.1 (0x2aac3000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0036a2e0) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x003a8440) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x003a8340) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x003a83c0) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x003a8280) libssl.so.6 => /lib64/libssl.so.6 (0x0035afc0) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0035b080) libresolv.so.2 => /lib64/libresolv.so.2 (0x003a82c0) libidn.so.11 => /usr/lib64/libidn.so.11 (0x003a8200) libc.so.6 => /lib64/libc.so.6 (0x003a8040) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003a8400) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x003a84c0) libpthread.so.0 => /lib64/libpthread.so.0 (0x003a8100) /lib64/ld-linux-x86-64.so.2 (0x003a8000) libnsl.so.1 => /lib64/libnsl.so.1 (0x003a8240) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x003a8480) [2010-06-11 16:10:16] tony2...@php.net Please also show the output of `ldd /path/to/php-fpm`. Thanks. [2010-06-11 15:36:27] marcus at adolfsson dot com This is my conf file: ; ; FPM Configuration ; ; ;include=/etc/fpm.d/*.conf ;; ; Global Options ; ;; [global] pid = /usr/logs/php-fpm.pid error_log = /usr/logs/php-fpm.log ; Log level ; Possible Values: alert, error, warning, notice, debug log_level = notice ; If this number of child processes exit with SIGSEGV or SIGBUS within the time ; interval set by emergency_restart_interval then FPM will restart. A value ; of '0' means 'Off'. ; Default Value: 0 emergency_restart_threshold = 10 ; Interval of time used by emergency_restart_interval to determine when ; a graceful restart will be initiated. This can be useful to work around ; accidental corruptions in an accelerator's shared memory. ; Available Units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 emergency_restart_interval = 1m ; Time limit for child processes to wait for a reaction on signals from master. ; Available units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 process_control_timeout = 5s ; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging. ; Default Value: yes daemonize = yes ; Pool Definitions ; ; Multiple pools of child processes may be started with different listening ; ports and different management options. The name of the pool will be ; used in logs and stats. There is no limitation on the number of pools which ; FPM can handle. Your system will tell you anyway :) ; Start a new pool named 'www'. [www] ; The address on which to accept FastCGI requests. ; Valid syntaxes are: ; 'ip.add.re.ss:port'- to listen on a TCP socket to a specific address on ;
Bug #49867 [Com]: spl_autoload crashes when called in write function of custom sessionSaveHandler
Edit report at http://bugs.php.net/bug.php?id=49867&edit=1 ID: 49867 Comment by: zapparov at member dot fsf dot org Reported by: nicolas dot lepage at yahoo dot fr Summary: spl_autoload crashes when called in write function of custom sessionSaveHandler Status: No Feedback Type: Bug Package: SPL related Operating System: * PHP Version: 5.3.0 New Comment: Unfortunately not for me. Also, by some reason this problem occurs only on some requests. I'll try to prepare a simple test which will reproduce this issue soonly. Previous Comments: [2010-06-12 15:48:06] ras...@php.net Doesn't calling session_write_close() completely solve this issue? [2010-06-12 12:23:24] zapparov at member dot fsf dot org Forgot to say - error occurs wonly when APC is enabled. [2010-06-12 11:24:11] zapparov at member dot fsf dot org Hello, Have exactly the same problem with Zend Framework + Doctrine (they both register own autoloaders). So when APC is enabled - it reproduces same fatal error. I'll try to gather more information about what happens little bit later. My PHP version is 5.3.2 [2010-03-09 08:30:14] travisghansen at yahoo dot com After many hours I finally found this bug report and I am experiencing this same issue. With a little guidance (I don't claim to be an expert) I'd be happy to provide a self contained script. [2010-02-19 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49867 -- Edit this bug report at http://bugs.php.net/bug.php?id=49867&edit=1
Bug #49867 [Com]: spl_autoload crashes when called in write function of custom sessionSaveHandler
Edit report at http://bugs.php.net/bug.php?id=49867&edit=1 ID: 49867 Comment by: zapparov at member dot fsf dot org Reported by: nicolas dot lepage at yahoo dot fr Summary: spl_autoload crashes when called in write function of custom sessionSaveHandler Status: No Feedback Type: Bug Package: SPL related Operating System: * PHP Version: 5.3.0 New Comment: And one more interesting thing. This Fatal error is thrown (!) after all operations were completed - so Im receiving exactly what I was expecting to receive but with Fatal Error and it's trace appended to it. o_O Previous Comments: [2010-06-12 23:34:44] zapparov at member dot fsf dot org Unfortunately not for me. Also, by some reason this problem occurs only on some requests. I'll try to prepare a simple test which will reproduce this issue soonly. [2010-06-12 15:48:06] ras...@php.net Doesn't calling session_write_close() completely solve this issue? [2010-06-12 12:23:24] zapparov at member dot fsf dot org Forgot to say - error occurs wonly when APC is enabled. [2010-06-12 11:24:11] zapparov at member dot fsf dot org Hello, Have exactly the same problem with Zend Framework + Doctrine (they both register own autoloaders). So when APC is enabled - it reproduces same fatal error. I'll try to gather more information about what happens little bit later. My PHP version is 5.3.2 [2010-03-09 08:30:14] travisghansen at yahoo dot com After many hours I finally found this bug report and I am experiencing this same issue. With a little guidance (I don't claim to be an expert) I'd be happy to provide a self contained script. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49867 -- Edit this bug report at http://bugs.php.net/bug.php?id=49867&edit=1
Bug #52053 [Opn->Csd]: PDO constructor returns null instead of throwing an exception
Edit report at http://bugs.php.net/bug.php?id=52053&edit=1
ID: 52053
Updated by: fel...@php.net
Reported by: zabruska at tugamail dot pt
Summary: PDO constructor returns null instead of throwing an
exception
-Status: Open
+Status: Closed
Type: Bug
Package: PDO related
Operating System: Ubuntu 9.10
PHP Version: 5.3.2
-Assigned To:
+Assigned To: felipe
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Closing the Bug #49320 as well.
Previous Comments:
[2010-06-11 19:36:35] zabruska at tugamail dot pt
Description:
Calling 'new PDO(...)' returns null instead of raising an exception.
This behaviour was found, while trying to create a PDO object using an
sqlite database.
The database was created using the command 'sqlite3' from the console.
Attempting to open it from PHP using an 'sqlite2' dsn did not raised any
exception, but returned null from the object constructor.
I do not know if this happens with other PDO drivers, but in any case
constructors SHOULD throw an Exception on error, and not NULL.
A similar bug has been reported (http://bugs.php.net/bug.php?id=49320)
but since there is at least another case
(http://bugs.php.net/bug.php?id=52042) in which a constructor returns
NULL when it should be throwing an Exception, I decided to report this
anyway.
I'm not sure if this goes beyond PDO, and it's a PHP feature that I've
never experienced before, but this type of code makes no sense at all,
$o = new SomeObject();
if($o === null) {
// handle error ...
} else {
$o->doSomething();
}
This is what is expected from OOP:
try {
$o = new SomeObject();
$o->doSomething();
} catch(Exception $x) {
// handle error ...
}
Test script:
---
>From the console:
$ sqlite3 sqlite.db
sqlite> CREATE TABLE T(K VARCHAR(32));
sqlite> .q
>From a PHP script:
$pdo = new PDO('sqlite2:sqlite.db');
echo 'PDO is ', gettype($pdo), PHP_EOL;
Expected result:
PDO is object
Actual result:
--
PDO is NULL
--
Edit this bug report at http://bugs.php.net/bug.php?id=52053&edit=1
Bug #49320 [NoF->Csd]: PDO returns null when SQLite connection fails
Edit report at http://bugs.php.net/bug.php?id=49320&edit=1 ID: 49320 Updated by: fel...@php.net Reported by: brandon at brandonsavage dot net Summary: PDO returns null when SQLite connection fails -Status: No Feedback +Status: Closed Type: Bug Package: PDO related Operating System: All PHP Version: 5.2.10 -Assigned To: +Assigned To: felipe New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-06-13 00:04:50] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=300413 Log: - Fixed bug #49320 (PDO returns null when SQLite connection fails) [2009-12-14 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-12-06 22:15:50] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-08-21 14:16:08] brandon at brandonsavage dot net The version is mentioned as 5.2.10 but i tested this in 5.3.0 and it exists there as well. [2009-08-21 13:45:15] brandon at brandonsavage dot net Description: The PDO extension should either return an object or throw an exception. However, with PDO and the SQLite driver, this does not happen. Reproduce code: --- http://bugs.php.net/bug.php?id=49320&edit=1
[PHP-BUG] Bug #52070 [NEW]: imagedashedline() - dashed line sometimes is not visible
From:
Operating system: WinXP - IIS -fastcgi
PHP version: 5.3.2
Package: GD related
Bug Type: Bug
Bug description:imagedashedline() - dashed line sometimes is not visible
Description:
This bug first was realized by me in php 5.3.1. imagedashedline() function
is not work properly. Tipically horizontal and sharp-angled dashed lines is
not visible after running this function. Could someone make a patch or fix
this problem?
I know this problem has already been realized in earlier versions also, but
not corrected yet.
Thanks,
Gabor
Test script:
---
$im=imagecreate(1200,800);
$background_color=imagecolorallocate($im,40,40,40);
$color=imagecolorallocate($im,255,255,255);
imagedashedline($im,800,400,300,400,$color); // not visible, horizontal
line
imagedashedline($im,800,400,300,800,$color); // not visible
imagedashedline($im,800,400,400,800,$color); // not visible
imagedashedline($im,800,400,500,800,$color); // visible
imagedashedline($im,800,400,600,800,$color); // visible
imagedashedline($im,800,400,700,800,$color); // visible
imagedashedline($im,800,400,800,800,$color); // visible, vertical line
header("Content-type: image/png");
imagepng($im);
imagedestroy($im);
--
Edit bug report at http://bugs.php.net/bug.php?id=52070&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52070&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52070&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52070&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52070&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52070&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52070&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52070&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52070&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52070&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52070&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52070&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52070&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52070&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52070&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52070&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52070&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52070&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52070&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52070&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52070&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52070&r=mysqlcfg
Bug #52029 [Opn->Asn]: create_alias namespaces
Edit report at http://bugs.php.net/bug.php?id=52029&edit=1
ID: 52029
Updated by: fel...@php.net
Reported by: rustyj4ck at gmail dot com
Summary: create_alias namespaces
-Status: Open
+Status: Assigned
Type: Bug
-Package: Class/Object related
+Package: Scripting Engine problem
Operating System: all
PHP Version: 5.3.2
-Assigned To:
+Assigned To: dmitry
New Comment:
Hmm, in fact the alias is created by reusing the original class entry.
I.e. no copy is done, it just add a new entry to the class table using
the alias name pointing to the original one.
class a { }
class_alias('a', 'b');
ReflectionClass::export('b');
/*
Class [ class a ] {
...
}
*/
Dmitry, are actually the aliases supposed to behave in this way?
(needing to be explained in the documentation wether it is right as is)
Previous Comments:
[2010-06-09 13:08:28] rustyj4ck at gmail dot com
Description:
Cant create alias to class in different namespace.
Created object (alias instance) return type of base class,
not alias.
Test script:
---
_cl = get_class($this); }
function get_cl() { return $this->_cl; }
}
class core {
private $_cl;
function register($name) {
$from = 'tf\\core\\collection';
$to = 'tf\\users\\' . $name;
printf ("aliasing %s --> %s : %s \n", $from, $to,
class_alias($from, $to)?'OK':'FAIl');
$a = new $to ();
$this->_cl = get_class($a);
return $a;
}
function get_cl() { return $this->_cl; }
}
}
namespace {
use tf\core\core;
$core = new core();
$test = $core->register('test');
printf("core: %s, result: %s, get_class: %s \n",
$core->get_cl(), $test->get_cl(), get_class($test));
}
Expected result:
tf\users\test
Actual result:
--
aliasing tf\core\collection --> tf\users\test : OK
core: tf\core\collection, result: tf\core\collection, get_class:
tf\core\collection
--
Edit this bug report at http://bugs.php.net/bug.php?id=52029&edit=1
Bug #52064 [Com]: while loop does not meet conditions
Edit report at http://bugs.php.net/bug.php?id=52064&edit=1
ID: 52064
Comment by: developers at proneticas dot net
Reported by: developers at proneticas dot net
Summary: while loop does not meet conditions
Status: Feedback
Type: Bug
Package: *General Issues
Operating System: FreeBSD
PHP Version: 5.3.2
New Comment:
Well really any version of 5.2 was working correctly, but for the sake
of debugging, the last version of 5.2 installed was 5.2.12.
Previous Comments:
[2010-06-12 18:36:10] fel...@php.net
Which 5.2 release are you refering to?
[2010-06-12 12:51:58] developers at proneticas dot net
Description:
I am seeing a bug in PHP 5.3 where the WHILE LOOP is not meeting all of
the conditions. The same code was working great in PHP 5.2 but broke
after a PHP upgrade. I reviewed the PHP 5.3 change-log and nothing is
mentioned for changes in WHILE LOOP conditions.
Test script:
---
0)) {
$rlength--;
}
if ($rlength== 0) {
return substr($string, 0, $setlength);
} else {
return substr($string, 0, $rlength).'.';
}
}else {
return $string;
}
}
$mstr = 'ProNeticas has released a visual rapid database design tool.
This allows you to generate online programs in rapid time, without any
programming.';
print cutTextPer( (String)$mstr, 52);
?>
[OUTPUT IN PHP 5.2]
ProNeticas has released a visual rapid database design tool.
[OUTPUT IN PHP 5.3]
ProNeticas has released a visual rapid database de
Expected result:
ProNeticas has released a visual rapid database design tool.
Actual result:
--
ProNeticas has released a visual rapid database de
--
Edit this bug report at http://bugs.php.net/bug.php?id=52064&edit=1
Bug #51897 [Opn->Asn]: LIBXML_NOWARNING does not suppress warnings when passed to xinclude().
Edit report at http://bugs.php.net/bug.php?id=51897&edit=1
ID: 51897
Updated by: fel...@php.net
Reported by: rquadl...@php.net
Summary: LIBXML_NOWARNING does not suppress warnings when
passed to xinclude().
-Status: Open
+Status: Assigned
Type: Bug
Package: DOM XML related
Operating System: Windows XP SP3
PHP Version: 5.3.2
-Assigned To:
+Assigned To: rrichards
Previous Comments:
[2010-05-24 12:35:56] rquadl...@php.net
Description:
This issue is in relation to http://news.php.net/php.doc/969381854
Trying to standardise the documentation in relation to including class
synopsis,
I'm including constructor and destructor synopsis via an xinclude with
an
pointer and a xfallback...
http://docbook.org/ns/docbook)
xpointer(id('class.datetime')/db:refentry/db:refsec...@role='description']/desce
ndant::db:destructorsynopsis[not(@role='procedural')])">
As there is no destructor for datetime, the fallback is used (which is
empty).
All would seem to be well.
The problem is that the xinclude processing generates a warning when
using the
online documentation editor - but not when I run this locally via
phpdoc's
configure.
I've been supplied a test script (http://news.php.net/php.doc/969381870)
which
will generate the errors locally.
And so to the bug.
In the example the xinclude() call has no parameters.
Supplying LIBXML_NOWARNING does _NOT_ suppress the warnings.
To run the test script, you will need the doc-base/manual.xml file
produced by
running the doc-base/configure.php script (part of PHPDoc).
Test script:
---
load('doc-base/manual.xml', LIBXML_NOENT);
var_dump($doc->xinclude(LIBXML_NOWARNING));
var_dump($doc->validate());
?>
Expected result:
int(-1)
bool(true)
Actual result:
--
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.datetime')/db:refentry/db:refsec...@role='description']/desce
ndant::db:destructorsynopsis[not(@role='procedural')]) in - on line 4
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.datetimezone')/db:refentry/db:refsec...@role='description']/d
escendant::db:destructorsynopsis[not(@role='procedural')]) in - on line
4
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateinterval')/db:refentry/db:refsec...@role='description']/d
escendant::db:destructorsynopsis[not(@role='procedural')]) in - on line
4
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsec...@role='description']/des
cendant::db:destructorsynopsis[not(@role='procedural')]) in - on line 4
Warning: DOMDocument::xinclude(): XPointer evaluation failed:
#xmlns(db=http://docbook.org/ns/docbook)
xpointer(id('class.dateperiod')/db:refentry/db:refsec...@role='description']/des
cendant::db:methodsynopsis[not(@role='procedural')]) in - on line 4
int(-1)
bool(true)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51897&edit=1
Bug #52058 [Opn->Ver]: SOAP_PERSISTENCE_SESSION doesnt work if server class is included from external
Edit report at http://bugs.php.net/bug.php?id=52058&edit=1
ID: 52058
Updated by: fel...@php.net
Reported by: nn at tronix dot pl
Summary: SOAP_PERSISTENCE_SESSION doesnt work if server class
is included from external
-Status: Open
+Status: Verified
Type: Bug
Package: SOAP related
Operating System: FreeBSD 6.2
PHP Version: 5.3.2
New Comment:
I can reproduce it.
Previous Comments:
[2010-06-11 23:41:14] nn at tronix dot pl
The line 14 in server.php should be changed to:
$server = new SoapServer(NULL, array('uri' => 'http://localhost/'));
^^
[2010-06-11 23:35:26] nn at tronix dot pl
Description:
If server class is included / required (or included/required once) from
external file the persistence doesn't work.
I think that the BUG is related to already reported bugs #51561 and
#44267.
Test script:
---
client.php
"http://localhost/server.php";,
"uri" => "urn:xmethodsTest",
'trace' => 1
));
# SOAP requests
try {
$session = $client->login();
//$client->__setCookie('PSESSION', $session);
print $client->incVar(); print "\n";
print $client->incVar(); print "\n";
print $client->incVar(); print "\n";
print $client->incVar(); print "\n";
print $client->incVar(); print "\n";
} catch (SoapFault $sf) {
echo "";
echo $sf;
}
?>
server.php
--
'http://193.59.86.29/'));
$server->setClass('Bar');
$server->setPersistence(SOAP_PERSISTENCE_SESSION);
$server->handle();
?>
class.bar.php
--
var++;
return $this->var;
}
}
?>
Expected result:
1
2
3
4
5
Actual result:
--
1
1
1
1
1
--
Edit this bug report at http://bugs.php.net/bug.php?id=52058&edit=1
[PHP-BUG] Req #52071 [NEW]: RFE: ping
From: Operating system: Linux PHP version: Irrelevant Package: Network related Bug Type: Feature/Change Request Bug description:RFE: ping Description: Surprisingly, PHP is missing the ability to ping another host (and check it's alive). So I'd like to make a request to add it. I'd suggest using something like fping rather than standard ping, as this is more script-friendly - for example, fping can be made to return immediately as soon as it discovers that a given host is alive. For example: fping -q -B1 www.php.net I know that there is Net_Ping available via PEAR, but often PEAR extensions aren't available on many hosting environments; likewise it's awkward to package a PHP web-application when the PEAR extension isn't already packaged for the distro. Is ping suficiently fundamental to be considered core? Test script: --- This command should either exist in 2 forms, or have several options. Typical use cases are: 1. Is machine X alive (and responding to Pings) 2. Can I do a DNS lookup + route to that machine 3. What is the packet loss fraction. This is easy enough to do by using exec(), but it would be nice to have a native function. Thanks. -- Edit bug report at http://bugs.php.net/bug.php?id=52071&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52071&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52071&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52071&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52071&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52071&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52071&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52071&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52071&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52071&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52071&r=support Expected behavior: http://bugs.php.net/fix.php?id=52071&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52071&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52071&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52071&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52071&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52071&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52071&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52071&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52071&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52071&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52071&r=mysqlcfg
[PHP-BUG] Req #52072 [NEW]: RFE: can we have `which`
From:
Operating system: Linux
PHP version: Irrelevant
Package: Filesystem function related
Bug Type: Feature/Change Request
Bug description:RFE: can we have `which`
Description:
It would be nice if PHP had a builtin "which" command.
For example, which("ffmpeg") would allow the user to check whether ffmpeg
was installed, prior to calling it with exec().
Test script:
---
which("ffmpeg") should return eg:
/usr/bin/ffmpeg
if the command exists, and is in the £PATH for exec(), or
false
if it doesn't exist.
--
Edit bug report at http://bugs.php.net/bug.php?id=52072&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52072&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52072&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52072&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52072&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52072&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52072&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52072&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52072&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52072&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52072&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52072&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52072&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52072&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52072&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52072&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52072&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52072&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52072&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52072&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52072&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52072&r=mysqlcfg
Req #52071 [Opn->Wfx]: RFE: ping
Edit report at http://bugs.php.net/bug.php?id=52071&edit=1
ID: 52071
Updated by: ras...@php.net
Reported by: php at richardneill dot org
Summary: RFE: ping
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package: Network related
Operating System: Linux
PHP Version: Irrelevant
New Comment:
This is not going to work in most PHP environments because doing
raw-socket ICMP
requests, like ping does requires root access. You will notice that
your ping
binary is setuid-root on your machine, so unless you are running PHP as
root,
doing it from within PHP simply won't work.
If you do have root access, it isn't that hard to do with a
socket_create(AF_INET, SOCK_RAW, getprotobyname('icmp')) call, but
since it
wouldn't work for most people, I don't see the point in adding it to
PHP.
Previous Comments:
[2010-06-13 02:28:38] php at richardneill dot org
Description:
Surprisingly, PHP is missing the ability to ping another host (and check
it's
alive). So I'd like to make a request to add it. I'd suggest using
something
like fping rather than standard ping, as this is more script-friendly -
for
example, fping can be made to return immediately as soon as it discovers
that
a given host is alive. For example:
fping -q -B1 www.php.net
I know that there is Net_Ping available via PEAR, but often PEAR
extensions
aren't available on many hosting environments; likewise it's awkward to
package a PHP web-application when the PEAR extension isn't already
packaged
for the distro. Is ping suficiently fundamental to be considered core?
Test script:
---
This command should either exist in 2 forms, or have several options.
Typical use cases are:
1. Is machine X alive (and responding to Pings)
2. Can I do a DNS lookup + route to that machine
3. What is the packet loss fraction.
This is easy enough to do by using exec(), but it would be nice to have
a native function. Thanks.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52071&edit=1
Req #52072 [Opn->Wfx]: RFE: can we have `which`
Edit report at http://bugs.php.net/bug.php?id=52072&edit=1
ID: 52072
Updated by: ras...@php.net
Reported by: php at richardneill dot org
Summary: RFE: can we have `which`
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package: Filesystem function related
Operating System: Linux
PHP Version: Irrelevant
New Comment:
This seems trivial to do in userspace to me:
function which($cmd) {
$paths = explode(':',$_ENV['PATH']);
foreach($paths as $path) {
$p = $path.'/'.$cmd;
if(file_exists($p)) return $p;
}
return false;
}
Previous Comments:
[2010-06-13 02:34:12] php at richardneill dot org
Description:
It would be nice if PHP had a builtin "which" command.
For example, which("ffmpeg") would allow the user to check whether
ffmpeg
was installed, prior to calling it with exec().
Test script:
---
which("ffmpeg") should return eg:
/usr/bin/ffmpeg
if the command exists, and is in the £PATH for exec(), or
false
if it doesn't exist.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52072&edit=1
[PHP-BUG] Req #52073 [NEW]: RFE: a few more options to exec()
From:
Operating system:
PHP version: Irrelevant
Package: Program Execution
Bug Type: Feature/Change Request
Bug description:RFE: a few more options to exec()
Description:
Exec() is missing a few key features:
1. The ability to return STDERR separately from STDOUT.
At the moment, we can get STDOUT back in $output, but STDERR is either
logged (for php-cgi) or sent to the main script STDERR (for php-cli).
The user has the choice to append "2>&1", but it would be really helpful
to have stderr and stdout both returned in separate arrays.
2. The ability to choose the shell. At the moment, exec() uses apache's
shell,
which is usually /bin/sh (either as bash or ash depending on distro). If
bash-isms are required, we can work around this with "bash -c '.. '",
but
it would be a nice feature.
3. If a process is forked, then we'd like to get the PID, $!. Currently
this can only be achieved thus:
exec ("foo & echo $!", $output)
but we must sacrifice stdout for the purpose.
4. Optionally, some way to do execv("arg1", "arg2", "arg3")
Test script:
---
I'd suggest having a function:
exec( string $command
[, array &$stdout
[,int &$retval
[,array &$stderr
[,int &$pid
[,int options = BASH|SH|CSH ]
] ] ] ]
)
--
Edit bug report at http://bugs.php.net/bug.php?id=52073&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52073&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52073&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52073&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52073&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52073&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52073&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52073&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52073&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52073&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52073&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52073&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52073&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52073&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52073&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52073&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52073&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52073&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52073&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52073&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52073&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52073&r=mysqlcfg
[PHP-BUG] Req #52074 [NEW]: RFE: tempdir() countrpart to tempnam()
From: Operating system: PHP version: Irrelevant Package: Directory function related Bug Type: Feature/Change Request Bug description:RFE: tempdir() countrpart to tempnam() Description: It would be really useful to have the ability to create a tempdir, with a unique name, which we know we can write to, and will be automatically cleaned up. For example, if I want to run an external command (with exec() ) which will write to a file, where: - it must be known that file-creation can succeed - the file does not exist at the moment Test script: --- Some applications will refuse to overwrite an existing file (that we created with tempnam()), because they don't want to clobber it. What we effectively need is a race-free way to assign a temp-filename without actually creating the file. Using tmpfile() doesn't help, because we can't pass a file-handle to php's exec(). -- Edit bug report at http://bugs.php.net/bug.php?id=52074&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52074&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52074&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52074&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52074&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52074&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52074&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52074&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52074&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52074&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52074&r=support Expected behavior: http://bugs.php.net/fix.php?id=52074&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52074&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52074&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52074&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52074&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52074&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52074&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52074&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52074&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52074&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52074&r=mysqlcfg
Req #52072 [Wfx]: RFE: can we have `which`
Edit report at http://bugs.php.net/bug.php?id=52072&edit=1
ID: 52072
User updated by: php at richardneill dot org
Reported by: php at richardneill dot org
Summary: RFE: can we have `which`
Status: Wont fix
Type: Feature/Change Request
Package: Filesystem function related
Operating System: Linux
PHP Version: Irrelevant
New Comment:
Thanks for your quick reply. I agree - it's trivial to do in userspace.
The simplest way is just to
$lastline = exec ("which $ffmpeg", $output, $retval)
if (retval){
return ($lastline)
}else{
return ($false)
}
Indeed many of the PHP functions are trivial in that sense - one could
build file_get_contents() out of fopen(),file(),fclose(), or could avoid
using unlink by a call to system("rm filename").
However the attraction of PHP is that so many of the required functions
already exist and I don't have to write them. So I think that which()
would be a useful addition.
I'm particularly thinking of the cases where php-cli is an improvement
on shell-scripting.
Previous Comments:
[2010-06-13 02:47:08] ras...@php.net
This seems trivial to do in userspace to me:
function which($cmd) {
$paths = explode(':',$_ENV['PATH']);
foreach($paths as $path) {
$p = $path.'/'.$cmd;
if(file_exists($p)) return $p;
}
return false;
}
[2010-06-13 02:34:12] php at richardneill dot org
Description:
It would be nice if PHP had a builtin "which" command.
For example, which("ffmpeg") would allow the user to check whether
ffmpeg
was installed, prior to calling it with exec().
Test script:
---
which("ffmpeg") should return eg:
/usr/bin/ffmpeg
if the command exists, and is in the £PATH for exec(), or
false
if it doesn't exist.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52072&edit=1
Req #52072 [Wfx]: RFE: can we have `which`
Edit report at http://bugs.php.net/bug.php?id=52072&edit=1
ID: 52072
Updated by: ras...@php.net
Reported by: php at richardneill dot org
Summary: RFE: can we have `which`
Status: Wont fix
Type: Feature/Change Request
Package: Filesystem function related
Operating System: Linux
PHP Version: Irrelevant
New Comment:
Using exec is definitely not the best way to do that one. Anytime you
fork+exec a
new process you take on a significant performance penalty. Same goes
for your
system() example. But, if you can do it in a couple of lines without
resorting to
an exec(), then it is indeed trivial. file_get_contents() is slightly
more
complicated because of the streams support in it.
Previous Comments:
[2010-06-13 03:06:33] php at richardneill dot org
Thanks for your quick reply. I agree - it's trivial to do in userspace.
The simplest way is just to
$lastline = exec ("which $ffmpeg", $output, $retval)
if (retval){
return ($lastline)
}else{
return ($false)
}
Indeed many of the PHP functions are trivial in that sense - one could
build file_get_contents() out of fopen(),file(),fclose(), or could avoid
using unlink by a call to system("rm filename").
However the attraction of PHP is that so many of the required functions
already exist and I don't have to write them. So I think that which()
would be a useful addition.
I'm particularly thinking of the cases where php-cli is an improvement
on shell-scripting.
[2010-06-13 02:47:08] ras...@php.net
This seems trivial to do in userspace to me:
function which($cmd) {
$paths = explode(':',$_ENV['PATH']);
foreach($paths as $path) {
$p = $path.'/'.$cmd;
if(file_exists($p)) return $p;
}
return false;
}
[2010-06-13 02:34:12] php at richardneill dot org
Description:
It would be nice if PHP had a builtin "which" command.
For example, which("ffmpeg") would allow the user to check whether
ffmpeg
was installed, prior to calling it with exec().
Test script:
---
which("ffmpeg") should return eg:
/usr/bin/ffmpeg
if the command exists, and is in the £PATH for exec(), or
false
if it doesn't exist.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52072&edit=1
Req #52071 [Wfx]: RFE: ping
Edit report at http://bugs.php.net/bug.php?id=52071&edit=1
ID: 52071
User updated by: php at richardneill dot org
Reported by: php at richardneill dot org
Summary: RFE: ping
Status: Wont fix
Type: Feature/Change Request
Package: Network related
Operating System: Linux
PHP Version: Irrelevant
New Comment:
I do see your point. On the other hand, I can (as a normal user) quite
easily use ping by relying on that Setuid binary, via exec(). Wouldn't
this approach work?
(the key win here is to eliminate needing exec(), which tends to upset
nervous managers during code-review)
Previous Comments:
[2010-06-13 02:38:27] ras...@php.net
This is not going to work in most PHP environments because doing
raw-socket ICMP
requests, like ping does requires root access. You will notice that
your ping
binary is setuid-root on your machine, so unless you are running PHP as
root,
doing it from within PHP simply won't work.
If you do have root access, it isn't that hard to do with a
socket_create(AF_INET, SOCK_RAW, getprotobyname('icmp')) call, but
since it
wouldn't work for most people, I don't see the point in adding it to
PHP.
[2010-06-13 02:28:38] php at richardneill dot org
Description:
Surprisingly, PHP is missing the ability to ping another host (and check
it's
alive). So I'd like to make a request to add it. I'd suggest using
something
like fping rather than standard ping, as this is more script-friendly -
for
example, fping can be made to return immediately as soon as it discovers
that
a given host is alive. For example:
fping -q -B1 www.php.net
I know that there is Net_Ping available via PEAR, but often PEAR
extensions
aren't available on many hosting environments; likewise it's awkward to
package a PHP web-application when the PEAR extension isn't already
packaged
for the distro. Is ping suficiently fundamental to be considered core?
Test script:
---
This command should either exist in 2 forms, or have several options.
Typical use cases are:
1. Is machine X alive (and responding to Pings)
2. Can I do a DNS lookup + route to that machine
3. What is the packet loss fraction.
This is easy enough to do by using exec(), but it would be nice to have
a native function. Thanks.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52071&edit=1
Req #52071 [Wfx]: RFE: ping
Edit report at http://bugs.php.net/bug.php?id=52071&edit=1
ID: 52071
Updated by: ras...@php.net
Reported by: php at richardneill dot org
Summary: RFE: ping
Status: Wont fix
Type: Feature/Change Request
Package: Network related
Operating System: Linux
PHP Version: Irrelevant
New Comment:
But the reason the exec() works is because you are starting a new
setuid-root
process to do it. There is no way to do it from a non-root process,
which means
you can't eliminate the exec(), which means a PHP implementation would
internally
have to do exec('ping') which makes no sense.
Previous Comments:
[2010-06-13 03:13:07] php at richardneill dot org
I do see your point. On the other hand, I can (as a normal user) quite
easily use ping by relying on that Setuid binary, via exec(). Wouldn't
this approach work?
(the key win here is to eliminate needing exec(), which tends to upset
nervous managers during code-review)
[2010-06-13 02:38:27] ras...@php.net
This is not going to work in most PHP environments because doing
raw-socket ICMP
requests, like ping does requires root access. You will notice that
your ping
binary is setuid-root on your machine, so unless you are running PHP as
root,
doing it from within PHP simply won't work.
If you do have root access, it isn't that hard to do with a
socket_create(AF_INET, SOCK_RAW, getprotobyname('icmp')) call, but
since it
wouldn't work for most people, I don't see the point in adding it to
PHP.
[2010-06-13 02:28:38] php at richardneill dot org
Description:
Surprisingly, PHP is missing the ability to ping another host (and check
it's
alive). So I'd like to make a request to add it. I'd suggest using
something
like fping rather than standard ping, as this is more script-friendly -
for
example, fping can be made to return immediately as soon as it discovers
that
a given host is alive. For example:
fping -q -B1 www.php.net
I know that there is Net_Ping available via PEAR, but often PEAR
extensions
aren't available on many hosting environments; likewise it's awkward to
package a PHP web-application when the PEAR extension isn't already
packaged
for the distro. Is ping suficiently fundamental to be considered core?
Test script:
---
This command should either exist in 2 forms, or have several options.
Typical use cases are:
1. Is machine X alive (and responding to Pings)
2. Can I do a DNS lookup + route to that machine
3. What is the packet loss fraction.
This is easy enough to do by using exec(), but it would be nice to have
a native function. Thanks.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52071&edit=1
Req #52073 [Opn->Bgs]: RFE: a few more options to exec()
Edit report at http://bugs.php.net/bug.php?id=52073&edit=1
ID: 52073
Updated by: ras...@php.net
Reported by: php at richardneill dot org
Summary: RFE: a few more options to exec()
-Status: Open
+Status: Bogus
Type:Feature/Change Request
Package: Program Execution
PHP Version: Irrelevant
New Comment:
This is what proc_open() is for.
Previous Comments:
[2010-06-13 02:48:15] php at richardneill dot org
Description:
Exec() is missing a few key features:
1. The ability to return STDERR separately from STDOUT.
At the moment, we can get STDOUT back in $output, but STDERR is either
logged (for php-cgi) or sent to the main script STDERR (for php-cli).
The user has the choice to append "2>&1", but it would be really
helpful
to have stderr and stdout both returned in separate arrays.
2. The ability to choose the shell. At the moment, exec() uses apache's
shell,
which is usually /bin/sh (either as bash or ash depending on distro).
If
bash-isms are required, we can work around this with "bash -c '..
'", but
it would be a nice feature.
3. If a process is forked, then we'd like to get the PID, $!. Currently
this can only be achieved thus:
exec ("foo & echo $!", $output)
but we must sacrifice stdout for the purpose.
4. Optionally, some way to do execv("arg1", "arg2", "arg3")
Test script:
---
I'd suggest having a function:
exec( string $command
[, array &$stdout
[,int &$retval
[,array &$stderr
[,int &$pid
[,int options = BASH|SH|CSH ]
] ] ] ]
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=52073&edit=1
Bug #22890 [Com]: CLI setuid scripts don't run setuid
Edit report at http://bugs.php.net/bug.php?id=22890&edit=1 ID: 22890 Comment by: php at richardneill dot org Reported by: gavin at itmerge dot com Summary: CLI setuid scripts don't run setuid Status: Bogus Type: Bug Package: CGI related Operating System: Linux 2.4.18 PHP Version: 4.3.1 New Comment: In 2003, the response was: "There are no plans to implement any perl-like workaround in PHP at the present time." Might I request that, 7 years later, and with much increased use of php as a general-purpose scripting language, it might be worth re-visiting this? Previous Comments: [2003-03-26 09:38:21] il...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Uid of the binary, which is PHP is what matters, the script's uid does not matter since it is a parameter. [2003-03-26 09:36:02] ed...@php.net Modern kernels on Unix and Unix-like operating systems simply ignore set uid bit on shebang scripts (those that begin with #!). Some interpreters (like perl) choose to implement workaraounds, but if you really need to make a script suid, it is very easy to achieve so with a simple C wrapper program. There are no plans to implement any perl-like workaround in PHP at the present time. [2003-03-26 04:05:29] gavin at itmerge dot com whoops spelt posix_geteuid(); wrong :P [2003-03-26 03:27:23] gavin at itmerge dot com /* my sample script is */ #!/usr/local/bin/php /* root#chown root.vhost /scripts/myscript root#chmod 4710 /scripts/myscript root#useradd -u 1001 gavin root#usermod gavin -G vhost root#logout gavin$/scripts/myscript 1001 gavin$ i had to create /usr/local/bin/setuid_php and chmod 4710 it to be able to make my php scripts run setuid root (i'm not a perl person i don't know if perl supports setuid but I know scripts that i pass thru /bin/zsh support setuid) I don't really like having that script there :0 because A, I'm learning but i'm learing quickly that the more "permissions" you have the more you're likely to get a stuck up the rear end and essentially that lets anyone become god on my system who might find it, I think i'm going to go move it outside of /usr/local/bin right now */ -- Edit this bug report at http://bugs.php.net/bug.php?id=22890&edit=1
Req #52071 [Wfx]: RFE: ping
Edit report at http://bugs.php.net/bug.php?id=52071&edit=1
ID: 52071
User updated by: php at richardneill dot org
Reported by: php at richardneill dot org
Summary: RFE: ping
Status: Wont fix
Type: Feature/Change Request
Package: Network related
Operating System: Linux
PHP Version: Irrelevant
New Comment:
Agreed: php would have to internally exec('ping'). That's not especially
pretty, but it's no uglier than having to explicitly do it. The
advantage is that the code (and all error cases) have to be handled only
once within PHP, rather than by ten thousand different end-users :-)
Previous Comments:
[2010-06-13 03:15:15] ras...@php.net
But the reason the exec() works is because you are starting a new
setuid-root
process to do it. There is no way to do it from a non-root process,
which means
you can't eliminate the exec(), which means a PHP implementation would
internally
have to do exec('ping') which makes no sense.
[2010-06-13 03:13:07] php at richardneill dot org
I do see your point. On the other hand, I can (as a normal user) quite
easily use ping by relying on that Setuid binary, via exec(). Wouldn't
this approach work?
(the key win here is to eliminate needing exec(), which tends to upset
nervous managers during code-review)
[2010-06-13 02:38:27] ras...@php.net
This is not going to work in most PHP environments because doing
raw-socket ICMP
requests, like ping does requires root access. You will notice that
your ping
binary is setuid-root on your machine, so unless you are running PHP as
root,
doing it from within PHP simply won't work.
If you do have root access, it isn't that hard to do with a
socket_create(AF_INET, SOCK_RAW, getprotobyname('icmp')) call, but
since it
wouldn't work for most people, I don't see the point in adding it to
PHP.
[2010-06-13 02:28:38] php at richardneill dot org
Description:
Surprisingly, PHP is missing the ability to ping another host (and check
it's
alive). So I'd like to make a request to add it. I'd suggest using
something
like fping rather than standard ping, as this is more script-friendly -
for
example, fping can be made to return immediately as soon as it discovers
that
a given host is alive. For example:
fping -q -B1 www.php.net
I know that there is Net_Ping available via PEAR, but often PEAR
extensions
aren't available on many hosting environments; likewise it's awkward to
package a PHP web-application when the PEAR extension isn't already
packaged
for the distro. Is ping suficiently fundamental to be considered core?
Test script:
---
This command should either exist in 2 forms, or have several options.
Typical use cases are:
1. Is machine X alive (and responding to Pings)
2. Can I do a DNS lookup + route to that machine
3. What is the packet loss fraction.
This is easy enough to do by using exec(), but it would be nice to have
a native function. Thanks.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52071&edit=1
Bug #49051 [Com]: XMLWriter::openURI() cannot resolve file path containing slash
Edit report at http://bugs.php.net/bug.php?id=49051&edit=1
ID: 49051
Comment by: dandandare at yahoo dot es
Reported by: major at minet dot sk
Summary: XMLWriter::openURI() cannot resolve file path
containing slash
Status: No Feedback
Type: Bug
Package: XML Writer
Operating System: Vista 32bit
PHP Version: 5.3.0
New Comment:
PHP Version: 5.3.1
OS Version: XP SP3 32bit
$xml->openURI('file.xml'); -> ok!
$xml->openURI('../file.xml'); -> ok!
$xml->openURI('xml/file.xml'); -> DON'T WORK!
$xml->openURI('../xml/file.xml'); -> DON'T WORK!
Don't work when you tries to access to a directory, why?
Previous Comments:
[2010-02-24 01:00:02] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2010-02-16 10:09:30] paj...@php.net
@afpral dot com at gmail dot com
Be sure that the directory exists (data/).
[2010-02-16 09:57:30] afpral dot com at gmail dot com
Warning: XMLWriter::openUri() [xmlwriter.openuri]: Unable to resolve
file path
With DIRECTORY_SEPARATOR uri to
not the same issue with only file name.
Parse filepath problem
[2009-08-01 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2009-07-24 17:12:20] j...@php.net
Since when is 'data/file.xml' a valid URI? Try with proper URI instead.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=49051
--
Edit this bug report at http://bugs.php.net/bug.php?id=49051&edit=1
Req #52073 [Bgs]: RFE: a few more options to exec()
Edit report at http://bugs.php.net/bug.php?id=52073&edit=1
ID: 52073
User updated by: php at richardneill dot org
Reported by: php at richardneill dot org
Summary: RFE: a few more options to exec()
Status: Bogus
Type:Feature/Change Request
Package: Program Execution
PHP Version: Irrelevant
New Comment:
Yesbut proc_open() is often very much long-winded overkill.
If I just want to get stdout and stderr as simple strings, what would be
most useful would be this:
exec ("echo hello >&2 ; echo world", $stdout, $stderr, $retval);
// $stdout = "hello\n"
// $stderr = "world\n";
// $retval = 0
the purpose here is to do everything in a minimum number of lines of
code.
I agree that for the entire set of suggestions, proc_open() is a better
solution, but for the common case of getting stdout and stderr back
separately,
I'd like to see an extra parameter in exec().
Also, the documentation for exec() doesn't explain where stderr goes.
Previous Comments:
[2010-06-13 03:20:58] ras...@php.net
This is what proc_open() is for.
[2010-06-13 02:48:15] php at richardneill dot org
Description:
Exec() is missing a few key features:
1. The ability to return STDERR separately from STDOUT.
At the moment, we can get STDOUT back in $output, but STDERR is either
logged (for php-cgi) or sent to the main script STDERR (for php-cli).
The user has the choice to append "2>&1", but it would be really
helpful
to have stderr and stdout both returned in separate arrays.
2. The ability to choose the shell. At the moment, exec() uses apache's
shell,
which is usually /bin/sh (either as bash or ash depending on distro).
If
bash-isms are required, we can work around this with "bash -c '..
'", but
it would be a nice feature.
3. If a process is forked, then we'd like to get the PID, $!. Currently
this can only be achieved thus:
exec ("foo & echo $!", $output)
but we must sacrifice stdout for the purpose.
4. Optionally, some way to do execv("arg1", "arg2", "arg3")
Test script:
---
I'd suggest having a function:
exec( string $command
[, array &$stdout
[,int &$retval
[,array &$stderr
[,int &$pid
[,int options = BASH|SH|CSH ]
] ] ] ]
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=52073&edit=1
