Cannot reproduce this any more.
(It occured on two different Debian unstable installations, with PHP5-beta3
on apache 1.3.29(?) and the other with PHP5-RC1 on apache-ssl 1.3.29.0.2-4),
with the same result: file could be read, still is_readable returned false).
Now, let's hope I just missed somet
> > Tampering with a coWiki (www.cowiki.org) plugin, I noticed that
> > is_readable() returns false, when PHP actually *can* read the file.
> > (Just commented out an "if (!is_readable($sRealPath))" and then
> > all went fine, the plugin now can read the files...)
> >
> > Is there a known reason fo
Dear Marcus:
> most probably the file rights prevent the web server from reading it.
As I mentioned: "PHP actually *can* read the file" -- and even though I
haven't explicitly said, most obviously I implied: from the web server.
> The function works as expected in 4.3.6rc as well as php5.
As I
stat() (of which is_readable() is a variant) was refactored slightly with
PHP5.
Take a look at the output of stat($sRealPath) and the user/group that the
webserver is running as. It'll also help to know what OS/webserver/sapi is
being used.
-Sara
- Original Message -
From: "Luna Kid" <
Hello Luna,
most probably the file rights prevent the web server from reading it.
The function works as expected in 4.3.6rc as well as php5.
Apart from that this is neither a bug list nor a support list.
marcus
Saturday, April 3, 2004, 1:56:11 AM, you wrote:
> Tampering with a coWiki (www.cowi
Tampering with a coWiki (www.cowiki.org) plugin, I noticed that
is_readable() returns false, when PHP actually *can* read the file.
(Just commented out an "if (!is_readable($sRealPath))" and then
all went fine, the plugin now can read the files...)
Is there a known reason for or has anoyone bumped
I'm not sure if this is true for the latest release but I'm working off
php4.3.4, slackware 9.0
ext/xslt/config.m4 doesn't add -lstdc++ for Sablot (not sure if its used by
other xslt backends) so I get undefined symbols for '__gxx_personality_v0'
and the like. Patch supplied.
-- --- ./ext/xslt
Did we ever come to a conclusion whether we're going to provide a
version of PHP 5 that bundles libxml2?
Now that we're in RC, I think we should aim to produce packages that
are as identical to the final release as possible, so we don't end up
with any unexpected surprises later on in the process.
On 2004/04/03, at 1:55, Ilia Alshanetsky wrote:
On April 2, 2004 11:42 am, Clemens Gutweiler wrote:
Uh, huh? The behaviour in 4.3.5 is the same as always. Nothing has
changed here. It was simple user error in that report.
Fixed.
Since when did people stop believing what I say? Anyway, I'm fine
On April 2, 2004 11:42 am, Clemens Gutweiler wrote:
> > Uh, huh? The behaviour in 4.3.5 is the same as always. Nothing has
> > changed here. It was simple user error in that report.
Fixed.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.
Hi Rasmus,
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
> Uh, huh? The behaviour in 4.3.5 is the same as always. Nothing has
> changed here. It was simple user error in that report.
Result of Ilia's test-script with PHP 4.3.3:
array(2) {
[0]=>
string(3) "one"
[1]=>
string(4) "va
Uh, huh? The behaviour in 4.3.5 is the same as always. Nothing has
changed here. It was simple user error in that report.
-Rasmus
On Fri, 2 Apr 2004, Moriyoshi Koizumi wrote:
> Hi,
>
> As this bug was already marked as a documentation problem and
> handled by Rasmus, but I don't think this is
Translating parts of documentation into Hungarian.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, 2 Apr 2004, Adam Maccabee Trachtenberg wrote:
> On Fri, 2 Apr 2004, Derick Rethans wrote:
>
> > *casting* works fine, we just don't do it automagically:
> >
> > print (string) $obj;
>
> Not anymore:
Yup, I know :)
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
On Fri, 2 Apr 2004, Derick Rethans wrote:
> *casting* works fine, we just don't do it automagically:
>
> print (string) $obj;
Not anymore:
class foo {
function __toString() {
return "I am a string.";
}
}
$foo = new foo;
print (string) $foo;
Object id #1
-adam
--
[EMAIL PROTECTED]
au
I've just tried the script an both PHP 4.3.6, 4.2.3 and 5.0 return the same
results.
Result:
array(2) {
[0]=>
string(3) "one"
[1]=>
string(4) "val1"
}
array(2) {
[0]=>
string(3) "two"
[1]=>
string(4) "val2"
}
array(1) {
[0]=>
string(0) ""
}
array(2) {
[0]=>
string(5) "t
The dup() is there "just-in-case" something breaks during PHP shutdown.
I don't remember now exactly what the potential problem(s) might have
been, so perhaps the dup is overly cautious.
So, I don't have a problem eliminating it, unless someone points out
a good reason to keep it :-)
--Wez.
Am 02.04.2004 um 09:49 schrieb Robin Ericsson:
On Thu, 2004-04-01 at 16:46, Derick Rethans wrote:
On Thu, 1 Apr 2004, Joseph Lee wrote:
What's with the logo on phpinfo() today?
The php logo has been changed to a dog. Is it a 1st April thing?
Yup
I liked Thies better than the dog :)
me too;-)
PS
Hello.
I'm trying to run a php script from xinetd (Fedora Linux). I need to close
stdin, stdout & stderr since I want to close
the socket established with the caller process (I have a long processing to
do locally, I need to release a remote
resource & closing the connection is the only way I can
4.3.6RC1 still has the nasty bug27582_2.phpt test which causes my dual xeon
machine to fall over on make test. Any chance of simply removing the test
before final release?
Cheers
--
Phil Driscoll
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
that kind, because versions prior to 4.3.5 returns an array
that contains a null string element and the script supplied
by the user on bug #27730 had worked flawlessly.
Here I mean: because in versions prior to 4.3.5 fgetcsv()
returns an array that contains a null string element for an
empty line..
Hi,
As this bug was already marked as a documentation problem and
handled by Rasmus, but I don't think this is a problem of
that kind, because versions prior to 4.3.5 returns an array
that contains a null string element and the script supplied
by the user on bug #27730 had worked flawlessly.
I thi
22 matches
Mail list logo
