But unfortunately neither of these fix the bug.
If there is php.ini in /, it's still used.
--Jani
On Thu, 12 Dec 2002, Moriyoshi Koizumi wrote:
+1 for applying this patch.
and attached is yet another fix as my suggestion.
(a bit dirty, and not tested enough).
Moriyoshi
On Thu, 12 Dec 2002, Derick Rethans wrote:
/configure --with-apxs=/usr/local/apache/bin/apxs
--with-config-file-path=/etc --with-mysql --with-mcrypt
--with-openssl=/us
r/local/ssl --with-imap-ssl=/usr/local/lib
Last option, the path..anything wrong in it?
--Jani
On Thu, 12 Dec 2002, Jani Taskinen wrote:
On Thu, 12 Dec 2002, Derick Rethans wrote:
/configure --with-apxs=/usr/local/apache/bin/apxs
--with-config-file-path=/etc --with-mysql --with-mcrypt
--with-openssl=/us
r/local/ssl --with-imap-ssl=/usr/local/lib
Last option, the
On Thu, 12 Dec 2002, Derick Rethans wrote:
On Thu, 12 Dec 2002, Jani Taskinen wrote:
On Thu, 12 Dec 2002, Derick Rethans wrote:
/configure --with-apxs=/usr/local/apache/bin/apxs
--with-config-file-path=/etc --with-mysql --with-mcrypt
--with-openssl=/us
r/local/ssl
On Thu, 12 Dec 2002, Jani Taskinen wrote:
On Thu, 12 Dec 2002, Derick Rethans wrote:
On Thu, 12 Dec 2002, Jani Taskinen wrote:
On Thu, 12 Dec 2002, Derick Rethans wrote:
/configure --with-apxs=/usr/local/apache/bin/apxs
--with-config-file-path=/etc --with-mysql --with-mcrypt
Hmm... it's natural that when apache is launched at /, it should read
/php.ini because of the current implementation shown below.
274 #ifdef INI_CHECK_CWD
275 if (strcmp(sapi_module.name, cli)!=0) {
276 if (*php_ini_search_path) {
277 strcat(php_ini_search_path,
On Thu, 12 Dec 2002, Moriyoshi Koizumi wrote:
Hmm... it's natural that when apache is launched at /, it should read
/php.ini because of the current implementation shown below.
274 #ifdef INI_CHECK_CWD
275 if (strcmp(sapi_module.name, cli)!=0) {
276if (*php_ini_search_path) {
277
I got a segmentation fault during configure php (today cvs) on Linux (SuSE
7.3, Kernel 2.4.20). Last line was checking getpwnam... no.
Regards, Kai
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, 12 Dec 2002, Jani Taskinen wrote:
On Thu, 12 Dec 2002, Moriyoshi Koizumi wrote:
Hmm... it's natural that when apache is launched at /, it should read
/php.ini because of the current implementation shown below.
274 #ifdef INI_CHECK_CWD
275 if (strcmp(sapi_module.name, cli)!=0) {
I know this thread is ridden to death but I want to add one argument for
completeness: If the cgi's name will be changed, thousands of administrators
need to fix their servers. But if the cli's name will be changed thousands
of end users of php cli scripts will have to change the scripts' shebang
Hi,
I know there was some hot discussion about this topic but I really need to get
this bug fixed. Even I'll make a patch with my zero knowledge of c if no one
would like to make it, but please try to find a reasonable sollution that
fits (almost) everyone's need.
I thought of one. I think a
You are right. I verified Apache changes the cwd to / unless it's been
launched in single process mode.
And I found results could be different by cases, using DSO or using CGI
executable. When you run your script with CGI executable and php.ini is
also present in that directory, the PHP binary
You are right. I verified Apache changes the cwd to / unless it's
been
launched in single process mode.
And I found results could be different by cases, using DSO or
using CGI
executable. When you run your script with CGI executable and
php.ini is
also present in that directory, the PHP
At the time CLI was introduced I argued to remove . from php.ini
search path, but that was not accepted because some people
apparently use this feature for having different configurations for
different virtual hosts.
Therefore . was removed only from CLI's php.ini search path.
This feature
firstly where can i add stuff to the cvs ? i have made a few posts before
about an issue that hasnt changed , you guys still dont have it patched
#if HAVE_LIBGD204
io_ctx-gd_free(io_ctx);
#else
io_ctx-free(io_ctx);
#endif
HAVE_LIBGD204 - this obviously means
No because it was preciselly because of cgi that CWD wasn't removed
from the php.ini search path. Have a look at the following thread:
http://www.zend.com/lists/php-dev/200202/msg01325.html
Edin
- Original Message -
From: Moriyoshi Koizumi [EMAIL PROTECTED]
To: Edin Kadribasic [EMAIL
The NEWS file mentions a new function getopt(), but I can not get this
to work under windows.
Fatal error: Call to undefined function: getopt()
My guess is that getopt() isn't a standard system function, but PHP
mimics the function as it handles command line arguments. Is this
intentional or
hmm better is:
#if HAVE_LIBGD = 204
io_ctx-gd_free(io_ctx);
#else
io_ctx-free(io_ctx);
#endif
or so, my C is not good my PHP is better :o) :P
or one makes which one ext/gd only with gd2.0.4 install can?
Electroteque [EMAIL PROTECTED] schrieb im Newsbeitrag
Thanks for the pointer. As far as I looked over the thread, which is not
so long as I expected, I don't feel there is that much need for including
CWD in php.ini search path. +1 for removing that feature.
Moriyoshi
Edin Kadribasic [EMAIL PROTECTED] wrote:
No because it was preciselly because
Kjartan Mannes wrote:
The NEWS file mentions a new function getopt(), but I can not get this
to work under windows.
Fatal error: Call to undefined function: getopt()
My guess is that getopt() isn't a standard system function, but PHP
mimics the function as it handles command line arguments.
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this forum is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
At 08:57
Hi Tom,
Did you ever get this problem solved?
I'm fighting the same issue - and if no better solution present it self,
I'm going
to do it by accessing a file of my choise. If the file doesn't exist -
create it and we
know we are in the first call. If it does exist - delete it, and we know
this is
Since more feedback may help here i also send this to php-dev
At 15:47 08.12.2002, Stanislav Malyshev wrote:
MB Therefor i would vote for allowing only decreasing the visibility or
force
MB to keep it.
Decreasing visibility contradicts the basic inheritance principle - that
derived class is-a
The best I ever came up with was doing what your saying but instead of using a
file I used an environment variable, it's still a mess but I think its probably
cleaner and safe than using file locking. I would still be interested if you
ever did find a proper solution though,
Sorry I can't help
=
FAILED TEST SUMMARY
-
OpenSSL private key functions [ext/openssl/tests/001.phpt]
getopt [ext/standard/tests/general_functions/getopt.phpt]
Simple math tests
Since version 1.197 of the cgi_main.c, cgi sapi will identify itself as
cgi-fcgi when compiled with fast cgi support (default on windows). This
breaks some PHP scripts and some C code, like PHP's dl() function. IMHO this
should be reverted to the old behavior regardless of the presence of fcgi
Jan Schneider schrieb:
I know this thread is ridden to death but I want to add
one argument for
completeness: If the cgi's name will be changed,
thousands of administrators
need to fix their servers. But if the cli's name will be
changed thousands
of end users of php cli scripts will have
MB 1) Visibility is about information hiding not showing.
Visibility is both hiding and showing. Visibility is defining what is
shown and what is hidden.
MB 2) You are wrong about 'is-a' in general. Our main problem here is that we
MB do not have a typecast operator.
I do not see why
With the new build system, is there a way to clean/build just one
extension, as opposed to having to do it to the whole tree? Something
like make clean ext=wddx, perhaps?
-Andrei http://www.gravitonic.com/
I must say I find television very educational. The
isn't it possible to cd to ext/wddx and make clean there?
Not sure but I think it's possible.
Andrey
- Original Message -
From: Andrei Zmievski [EMAIL PROTECTED]
To: PHP Developers [EMAIL PROTECTED]
Cc: Sascha Schumann [EMAIL PROTECTED]
Sent: Thursday, December 12, 2002 7:33 PM
Subject:
isn't it possible to cd to ext/wddx and make clean there?
Not sure but I think it's possible.
Nope, it is not :(
Andrey
Andrey
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Well may be i'm the only one (hard to say as nobody talk about this) but
i don't agree with accessors design, i allready posted a mail to Andrei
a month ago (may be lost, may be the wrong person) and i try here as
i'm sure someone will explain me 'why this design'.
Comment found in
On Thu, 12 Dec 2002, Andrei Zmievski wrote:
With the new build system, is there a way to clean/build just one
extension, as opposed to having to do it to the whole tree? Something
like make clean ext=wddx, perhaps?
We could add a target clean-ext-EXTNAME..
- Sascha
--
PHP
--- Sascha Schumann [EMAIL PROTECTED] wrote:
On Thu, 12 Dec 2002, Andrei Zmievski wrote:
With the new build system, is there a way to clean/build just one
extension, as opposed to having to do it to the whole tree? Something
like make clean ext=wddx, perhaps?
We could add a target
On Thu, 12 Dec 2002, Andrei Zmievski wrote:
With the new build system, is there a way to clean/build just one
extension, as opposed to having to do it to the whole tree? Something
like make clean ext=wddx, perhaps?
Install ccache? You'd still do a make clean for everything, but it
speeds up
On Thu, 12 Dec 2002, Sascha Schumann wrote:
We could add a target clean-ext-EXTNAME..
- Sascha
What about build-ext-EXTNAME? I ran into this yesterday when I checked
out a fresh copy of the tree and wanted to build only wddx module as a
shared library.
-Andrei
On Thu, 12 Dec 2002, Andrei Zmievski wrote:
On Thu, 12 Dec 2002, Sascha Schumann wrote:
We could add a target clean-ext-EXTNAME..
- Sascha
What about build-ext-EXTNAME? I ran into this yesterday when I checked
out a fresh copy of the tree and wanted to build only wddx module as
How about we simply add a configure option to control this?
--enable-simple-cli-name would build CGI as php-cgi and CLI as php
That way we preserve BC and let those who like CLI named 'php' have that
too.
-Andrei
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
How about we simply add a configure option to control this?
--enable-simple-cli-name would build CGI as php-cgi and CLI as php
That way we preserve BC and let those who like CLI named 'php' have that
too.
you mean instead of ::
# mv php-cli php
?
-Sterling
--
PHP Development Mailing
The original complaint in bug 20887 was that the CLI version was picking
up ini files in the wrong places. The patch I suggested last night does
address that problem (albiet not correctly, see below).
The secondary bug which isn't really a bug is the complaint that CWD is
included in the ini
On Thu, 12 Dec 2002, Sterling Hughes wrote:
How about we simply add a configure option to control this?
--enable-simple-cli-name would build CGI as php-cgi and CLI as php
That way we preserve BC and let those who like CLI named 'php' have that
too.
This will break the idea of
Hi,
The original complaint in bug 20887 was that the CLI version was picking
up ini files in the wrong places. The patch I suggested last night does
address that problem (albiet not correctly, see below).
??? The original report goes:
If /php.ini exists, that one is used no matter what
??? The original report goes:
If /php.ini exists, that one is used no matter what PHPRC env is set
or compiled in when starting up apache from a SysV script. Is it a bug
in php, or could it be the Mandrake Linux 9.0 system?
My bad, the fact does remain however, that there is a command line
Note that the patche is still incomplete because it dismisses many *nix OS
out there other than SunOS, Linux, FreeBSD, OpenBSD and NetBSD.
Moriyoshi
Sara Golemon [EMAIL PROTECTED] wrote:
??? The original report goes:
If /php.ini exists, that one is used no matter what PHPRC env is set
i'm sorry this is not fixed , i have RC03
In file included from /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:89:
/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c: In function
`_php_image_output_ctx':
/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c:73: structure has no
member named `free'
This is a different bug (xpm) caused by a bug in the external GD library, this
particular bug has been solved in the CVS. Unless you've patched your GD with
gif write support you have nothing to gain from not using the bundled
library, which offers more functionality and is more stable. The
sure i do but i have prefixed where gd is so it shouldnt be confused, its
obviously not checking for 2.0.8 ? i have made my patches to gd
s/php/php-4.3.0RC3/TSRM -g -O2 -prefer-pic -c
/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c -o ext/gd/gd.lo
/usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In
ok now its spits the dummy about freetype
In file included from
/usr/src/sources/php/php-4.3.0RC3/ext/gd/libgd/gdft.c:49:
/usr/local/etc/freetype/include/freetype2/freetype/freetype.h:41:22:
ft2build.h: No such file or directory
/usr/local/etc/freetype/include/freetype2/freetype/freetype.h:42:10:
When I say CV,S I am referring to the latest version of the PHP_4_3 tree, you
can download snapshots of that tree (generated every 2 hours) from
http://snaps.php.net
Ilia
On December 12, 2002 04:55 pm, electroteque wrote:
sure i do but i have prefixed where gd is so it shouldnt be confused,
Ilia A. wrote:
This is a different bug (xpm) caused by a bug in the external
GD library, this
particular bug has been solved in the CVS. Unless you've
patched your GD with
gif write support you have nothing to gain from not using the bundled
library, which offers more functionality and
On December 12, 2002 06:13 pm, Mike Robinson wrote:
Ilia A. wrote:
This is a different bug (xpm) caused by a bug in the external
GD library, this
particular bug has been solved in the CVS. Unless you've
patched your GD with
gif write support you have nothing to gain from not using the
[Stas answered you in a very thorough and accurate way, and since it took
several hours since I started composing this reply and the time I actually
sent it, I cut it down to minimum]
Marcus,
I (as well as basically all major OO languages I can think of) disagree
with you.
OO and inheritance
52 matches
Mail list logo
