Re: [PHP] Odd behavior
# [EMAIL PROTECTED] / 2006-12-24 18:11:03 -0800:
function display($list, $in, $out, $save, $req, $x)
{
for($i = 0; $i count($in); $i++)
{$j = $i + 1;
// two sets of links displayed instead of one
for($i = 0; $i count($out); $i++)
{$j = $i + 1;
// two sets of links displayed instead of one
for($i = 0; $i count($save); $i++)
{$j = $i + 1;
// two sets of links displayed instead of one
for($i = 0; $i count($req); $i++)
{$j = $i + 1;
// two sets of links displayed instead of one
The print lines above are supposed to produce a list of links to files.
In the web display I get duplicate sets of links which seems to mean
that the loops in the function are running twice, and in one instance
three times instead of once.
Look at the variable names you use for iteration.
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Odd behavior
On Dec 25, 2006, at 7:21 AM, Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2006-12-24 18:11:03 -0800:
function display($list, $in, $out, $save, $req, $x)
{
for($i = 0; $i count($in); $i++)
{$j = $i + 1;
// two sets of links displayed instead of one
for($i = 0; $i count($out); $i++)
{$j = $i + 1;
// two sets of links displayed instead of one
for($i = 0; $i count($save); $i++)
{$j = $i + 1;
// two sets of links displayed instead of one
for($i = 0; $i count($req); $i++)
{$j = $i + 1;
// two sets of links displayed instead of one
The print lines above are supposed to produce a list of links to
files.
In the web display I get duplicate sets of links which seems to mean
that the loops in the function are running twice, and in one instance
three times instead of once.
Look at the variable names you use for iteration.
Thanks, Usually, when a variable name like $i is used and then
reset to 0 in the next loop it does not matter. But I solved the
problem and posted the solution. I also solved the regex
problem. There was an extra \n sneaking into the test pattern
so I could not get a match. I am not sure where the extra \n is
coming from.
It looks like I didn't post the solution after all:
Update:
I solved the double loops problem with this code change:
function display($list, $a, $x)
{
for($i = 0; $i count($a); $i++)
{$j = $i + 1;
print a
href=\steps.php?list=$listnext=$jx=$x\$j/abrbr\n;
};
}
and:
if($list || $current)
{
switch($list)
{
case 'in':
display($list, $in, $x);
break;
case 'out':
display($list, $out, $x);
break;
case 'save':
display($list, $save, $x);
break;
case 'req':
display($list, $req, $x);
break;
}
}
Apparently what was happening was that the code running under 5.1.2
was trying to process all the arrays that had values in spite of the
switch
statement in the original display() function. If the was an $in array
the
switch would process that for the $list value being 'in' but since
there
was also a save value, the switch tried to process it also, even though
'save' wasn't the $list value. I found it would do this for all arrays
that
had values. So if three had values the loop selected loop would run
three times.
Could this be a bonafide bug?
JK
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Odd behavior
2006/12/25, jekillen [EMAIL PROTECTED]:
On Dec 25, 2006, at 7:21 AM, Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2006-12-24 18:11:03 -0800:
function display($list, $in, $out, $save, $req, $x)
{
for($i = 0; $i count($in); $i++)
{$j = $i + 1;
// two sets of links displayed instead of one
for($i = 0; $i count($out); $i++)
{$j = $i + 1;
// two sets of links displayed instead of one
for($i = 0; $i count($save); $i++)
{$j = $i + 1;
// two sets of links displayed instead of one
for($i = 0; $i count($req); $i++)
{$j = $i + 1;
// two sets of links displayed instead of one
The print lines above are supposed to produce a list of links to
files.
In the web display I get duplicate sets of links which seems to mean
that the loops in the function are running twice, and in one instance
three times instead of once.
Look at the variable names you use for iteration.
Thanks, Usually, when a variable name like $i is used and then
reset to 0 in the next loop it does not matter. But I solved the
problem and posted the solution. I also solved the regex
problem. There was an extra \n sneaking into the test pattern
so I could not get a match. I am not sure where the extra \n is
coming from.
It looks like I didn't post the solution after all:
Update:
I solved the double loops problem with this code change:
function display($list, $a, $x)
{
for($i = 0; $i count($a); $i++)
{$j = $i + 1;
print a
href=\steps.php?list=$listnext=$jx=$x\$j/abrbr\n;
};
}
and:
if($list || $current)
{
switch($list)
{
case 'in':
display($list, $in, $x);
break;
case 'out':
display($list, $out, $x);
break;
case 'save':
display($list, $save, $x);
break;
case 'req':
display($list, $req, $x);
break;
}
}
Apparently what was happening was that the code running under 5.1.2
was trying to process all the arrays that had values in spite of the
switch
statement in the original display() function. If the was an $in array
the
switch would process that for the $list value being 'in' but since
there
was also a save value, the switch tried to process it also, even though
'save' wasn't the $list value. I found it would do this for all arrays
that
had values. So if three had values the loop selected loop would run
three times.
Could this be a bonafide bug?
JK
I suspect this is an EBSAC bug, but I'm not completely sure. Anyway, please
consider improving your coding style, its all messy and unreadable. Also,
you should provide a description of the calling conditions, since there
might be the cause of the error in the function.
[PHP] Odd behavior
Hello,
Am having trouble with some code.
I have been developing a web based application on
a machine running php v4.3x, Apache 1.3x Mac OSX 10.3
The application works as expected on this machine.
So I copied the code to my server which is running FreeBSD
v6.0, Apache 1.3.34, php v5.1.2.
On this machine the exact same code does not work as expected
in some critical places.
Here is the code suspect of being troublesome:
include(process.php);
if(file_exists(in_tmp.php))
{
include(in_tmp.php);
}
if(file_exists(out_tmp.php))
{
include(out_tmp.php);
}
if(file_exists(save_tmp.php))
{
include(save_tmp.php);
}
if(file_exists(request_tmp.php))
{
include(request_tmp.php);
}
code snipped
function display($list, $in, $out, $save, $req, $x)
{
switch($list)
{
case 'in':
for($i = 0; $i count($in); $i++)
{$j = $i + 1;
print a
href=\steps.php?list=$listnext=$jx=$x\$j/abrbr;
// two sets of links displayed instead of one
};
break;
case 'out':
for($i = 0; $i count($out); $i++)
{$j = $i + 1;
print a
href=\steps.php?list=$listnext=$jx=$x\$j/abrbr;
// two sets of links displayed instead of one
};
break;
case 'save':
for($i = 0; $i count($save); $i++)
{$j = $i + 1;
print a
href=\steps.php?list=$listnext=$jx=$x\$j/abrbr;
// two sets of links displayed instead of one
};
break;
case 'requests':
for($i = 0; $i count($req); $i++)
{$j = $i + 1;
print a
href=\steps.php?list=$listnext=$jx=$x\$j/abrbr;
// two sets of links displayed instead of one
};
break;
};
}
The print lines above are supposed to produce a list of links to files.
In the web display I get duplicate sets of links which seems to mean
that the loops in the function are running twice, and in one instance
three times instead of once. The arrays are taken from the included
files. These files are php scripts produced by a php script after a
directory is opened and read. The arrays a declared and initialized
in these scripts. If there are no files in the directories, the scripts
are
not written (thus the code if(file_exists(so and so file) etc..).
Is there a difference in the behavior of include between php 4x and 5x?
I am also having problems with a regular expression:
$w = ereg(To:nbsp;nbsp;nbsp;nbsp;\n([ A-Za-z]*), $data, $m);
$x = ereg(recipient who='.$m[1].' to='(.*)' /, $rout, $m_1);
$dest = $m_1[1];
This code has opened and read a file and is picking out data from the
file
so it can use this data to copy the file to another directory. On my
dev server
this code works fine. On the production server this code will not pick
up the
match from the first regex and so will not find a match in the second.
Is this a difference between versions of php, known bugs, possibly a
problem with the php or Apache installation on my production server?
If nothing comes to anyone's mind, I will have to do some digging.
but if there is I would appreciate suggestions advice.
Thanks in advance.
JK
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior of stripos() with === operator *UPDATE*
At 12:24 AM 11/17/2006 , Michael wrote:
HEllo all,
After pulling my hair out for several hours trying to figure out why my code
wasn't working I built this little test and ran it, the results are interesting
in the least, and to me, surprising. It is possible that I have done something
wrong, but I checked and rechecked this in the documentation.
It appears there is either a problem with the === operator (or my brain...)
If you don't mind, I'd like to see what you all think.
I am running php 5.2.0 on a linux redhat 9 box with Apache 2.2 (the php 5.2.0
install is brand new, perhaps I set it up wrong?)
anyway here is the code I wrote, and the output from it...
$found = stripos(abcdefg, abcdefg);
echo found = stripos(\abcdefg\, \abcdefg\);\n
echo The value of found is = : $found\n
// 1a) --- needle was found in haystack THIS SHOULD BE
if ( $found !== FALSE ) {
echo found does not equal FALSE\n
}
// 1b) --- needle was found in haystack THIS SHOULD ALSO BE
if ($found === TRUE ) {
echo found is equal to TRUE\n
}
//1c) --- needle was NOT found in haystack THIS SHOULD NOT BE
if ( $found === FALSE ) {
echo found is equal to FALSE\n
}
//1d) --- needle was NOT found in haystack THIS ALSO SHOULD NOT BE
if ($found !== TRUE ) {
echo found does not equal TRUE\n
}
$found = stripos(abcdefg, tuvwxyz);
echo \$found = stripos(\abcdefg\, \tuvwxyz\);br\n
echo The value of found is = : $found\n
//2a) --- needle was found in haystack THIS SHOULD NOT BE
if ( $found !== FALSE ) {
echo found does not equal FALSE\n
}
//2b) --- needle was found in haystack THIS ALSO SHOULD NOT BE
if ($found === TRUE ) {
echo found is equal to TRUE\n
}
//2c) --- needle was NOT found in haystack THIS SHOULD BE
if ( $found === FALSE ) {
echo found is equal to FALSE\n
}
//2d) --- needle was NOT found in haystack THIS SHOULD ALSO BE
if ($found !== TRUE ) {
echo found does not equal TRUE\n
}
the output:
$found = stripos(abcdefg, abcdefg);
The value of found is = : 0
found does not equal FALSE //this is from section 1a) of the code
found does not equal TRUE//this is from section 1d) of the code
// I expected the code from 1b) to be executed
$found = stripos(abcdefg, tuvwxyz);
The value of found is = :
found is equal to FALSE //this is from section 2c) of the code
found does not equal TRUE//this is from section 2d) of the code
I have underlined the output I am interested in... How can the variable $found
be both TRUE and FALSE at the same time?
Anyone who can provide me some insight on this, please enlighten me.
If my code is correct, then this behavior of the === operator is
counter-intuitive, it was my understanding that the === and !== operators were
supposed to be used with the output of stripos() for just this situation, but
=== does not appear to recognize that the returned 0 (because the string was
found at index 0) ; whereas the !== does recognize this...
is === buggy? or am I? heh
thoughts? comments?
Thanks all,
Michael
Hello again,
I have tested and re-tested this to the point I am confident to update this
post with my findings...
given: $haystack=abcdef and $needle=abc
any use of stripos($haystack, $needle) === TRUE will return a FALSE RESULT.
In other words, if there is ANY chance that $needle will be found at the very
beginning of $haystack (index = 0), you CANNOT USE === TRUE, you must use
!== FALSE.
To me this behavior is counter-intuitive. If something is !== FALSE, then
=== TRUE should also be correct.
I understand why a string found at the beginning of another string returns an
integer 0 (the index at which the needle was found in the haystack) from
stripos(), however, my point is that you SHOULD be able to test this for a TRUE
condition as well as for a FALSE.
I'm not sure why the === operator does not handle this condition, since the
wonderful people at PHP foresaw the problem and fixed !== to handle it, I would
like to see the === fixed to handle this as well (if it is even possible, not
sure about how this is implemented??)
ANyway, just posting this update for posterity, in case anyone else tries to
test for === TRUE instead of !== FALSE with stripos() and checks here before
they spend hours debugging their code.
If anyone sees anything I did wrong that is causing this behavior PLEASE let me
know, I am no PHP Guru and I have no ego, and will humbly retract this post
if I am wrong. I would just like to know WHY and WHERE I am wrong :)
Thank you for your time.
Regards,
Michael
ps - ok ok. I know I can just use !== FALSE, just want to let others in the
community know about this :)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior of stripos() with === operator
Michael wrote: Ok, picking gnits... I should have said NOT true and NOT false at the same time. As for the return of the integer 0.. The documentation indicates that the === and !== operators take this into account in fact there is a specific example in the manual. My point here is that if !== works , why does === not? I think you need to re-read the docs for ===. 0 !== false 0 == false 1 == true 1 !== true only... false === false and true === true The === and !== check both value and type, so 0 and false are different. Hope that helped. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior of stripos() with === operator *UPDATE*
Michael wrote: I'm not sure why the === operator does not handle this condition, since the wonderful people at PHP foresaw the problem and fixed !== to handle it, I would like to see the === fixed to handle this as well (if it is even possible, not sure about how this is implemented??) This would not be a 'fix', this would be a break. Since !== and === are checking type *and* value, the logical truth of one does not necessarily mean the other will be false. Once you understand that it should all become clear. If anyone sees anything I did wrong that is causing this behavior PLEASE let me know, I am no PHP Guru and I have no ego, and will humbly retract this post if I am wrong. I would just like to know WHY and WHERE I am wrong :)= You're not doing anything wrong, you're just not quite getting the meaning of === and !== as opposed to == and !=. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior of stripos() with === operator
At 02:10 AM 11/17/2006 , Stut wrote:
Michael wrote:
Ok, picking gnits...
I should have said NOT true and NOT false at the same time.
As for the return of the integer 0..
The documentation indicates that the === and !== operators take this into
account in fact there is a specific example in the manual.
My point here is that if !== works , why does === not?
I think you need to re-read the docs for ===.
0 !== false
0 == false
1 == true
1 !== true
only...
false === false
and
true === true
The === and !== check both value and type, so 0 and false are different.
Hope that helped.
-Stut
--
Thanks for your reply Stut.
I understand that the integer 0 and FALSE are different and I read the manual
so many times my head hurts, heh.
There are a few ways to work around this, probably more than I know. (according
to the documentation for strrpos() you could test the return from stripos() for
is_bool before using it), or (perhaps, cast the return from stripos() to a
boolean, although integer 0 probably casts to false :/, I honestly didn't test
this {see }), or (easiest solution...just suck up and use !== FALSE all the
time :D )
My point in posting this was threefold,
1) to help others who may not know that stripos() returns an INTEGER 0 when the
needle is found at the beginning of haystack, and/or don't realize the
implications of that.
2) My main point is that !== works, so should ===. If !== knows the difference
between integer 0 and boolean FALSE, why doesn't ===?
3) to get feedback from the community and deepen my understanding of PHP.
So, I thank you very much for your reply :)
Regards,
Michael
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior of stripos() with === operator
At 02:33 AM 11/17/2006 , Stut wrote:
Michael wrote:
I understand that the integer 0 and FALSE are different and I read the
manual so many times my head hurts, heh.
There are a few ways to work around this, probably more than I know.
(according to the documentation for strrpos() you could test the return from
stripos() for is_bool before using it), or (perhaps, cast the return from
stripos() to a boolean, although integer 0 probably casts to false :/, I
honestly didn't test this {see }), or (easiest solution...just suck up
and use !== FALSE all the time :D )
I'm not understanding what you need to work around. What's wrong with
using !== false?
Nothing at all wrong with using !== FALSE :) I am doing so NOW :)
However, I DIDN'T know that (integer) 0 !== FALSE and (integer) 0 === TRUE are
not the same thing, perhaps someone else will gain from my experience here.
My point in posting this was threefold,
1) to help others who may not know that stripos() returns an INTEGER 0 when
the needle is found at the beginning of haystack, and/or don't realize the
implications of that.
The manual page for strpos and any other function that may return 0 or
false clearly make this point.
2) My main point is that !== works, so should ===. If !== knows the
difference between integer 0 and boolean FALSE, why doesn't ===?
It does, but it also knows the difference between 1 and true, 2 and
true, 3 and true, etc.
3) to get feedback from the community and deepen my understanding of PHP.
I'm trying ;)
I appreciate your efforts :) Thanks again!
-Stut
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior of stripos() with === operator *UPDATE*
Please include the list in replies. Michael wrote: Why can't === realize that integer 0 means TRUE? whereas or a BOOLEAN false does not? === evaluates integer 0 to FALSE :( the !== operator recognizes the difference. (integer) 0 !== FALSE is TRUE yet (integer) 0 === TRUE is FALSE, but it should also be TRUE. follow? or am I really stupid heh I value your opinion on this and if you need to take a stick to me to straighten me out, feel free :) A stick? Can do! You've said it yourself... (integer) 0 === TRUE is FALSE, but it should also be TRUE. This comparison says... Is the INTEGER 0 equal in both value *and* type to the BOOLEAN true? The answer of course is no. In exactly the same way that any comparison of different types using === will be false. Note that this has absolutely nothing to do with the fact that the value you are comparing has come from strpos, it is a basic language feature. And it's not my opinion, it's a fact. If that doesn't make it clear then I really don't know what will. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior of stripos() with === operator
Michael wrote:
I understand that the integer 0 and FALSE are different and I read the manual
so many times my head hurts, heh.
There are a few ways to work around this, probably more than I know. (according to the
documentation for strrpos() you could test the return from stripos() for is_bool before
using it), or (perhaps, cast the return from stripos() to a boolean, although integer 0
probably casts to false :/, I honestly didn't test this {see }), or (easiest
solution...just suck up and use !== FALSE all the time :D )
I'm not understanding what you need to work around. What's wrong with
using !== false?
My point in posting this was threefold,
1) to help others who may not know that stripos() returns an INTEGER 0 when the
needle is found at the beginning of haystack, and/or don't realize the
implications of that.
The manual page for strpos and any other function that may return 0 or
false clearly make this point.
2) My main point is that !== works, so should ===. If !== knows the difference
between integer 0 and boolean FALSE, why doesn't ===?
It does, but it also knows the difference between 1 and true, 2 and
true, 3 and true, etc.
3) to get feedback from the community and deepen my understanding of PHP.
I'm trying ;)
-Stut
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior of stripos() with === operator *LAST POST*
This will be my last post on this thread of discussion. Thanks to all who replied, I have it figured out. I guess my only problem with the way the !== and === operators work in this situation is this: Logic dictates that if something evaluates to NOT FALSE it must be TRUE. Regardless of the type, regardless of the species, breed, flavor etc. if !== evaluates to TRUE then === should also under the same conditions (all other things being equal) if !== evaluates an integer 0 to TRUE, so should ===, it can't be true and still return a false value. The !== and === operators work differently, they should be complimentary. Sorry if all this has inconvenienced anyone. Cheers, Michael -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] odd behavior of stripos() with === operator *LAST POST*
On 17 November 2006 09:55, Michael wrote:
This will be my last post on this thread of discussion.
Thanks to all who replied, I have it figured out.
I guess my only problem with the way the !== and ===
operators work in this situation is this:
Logic dictates that if something evaluates to NOT FALSE it
must be TRUE.
Um, yes, but it's the *test* that's evaluating to NOT FALSE (and obeys this
rule), which says nothing about the actual values involved in the test. Even
with the != operator you can demonstrate this point:
$x = yes;
if ($x!=FALSE) { echo \$x must be TRUE }
will display the message, even though $x contains the string yes (because the
string yes in a Boolean context evaluates to TRUE).
if !== evaluates to TRUE then === should also under the same
conditions (all other things being equal)
I don't think that's quite what you meant, but I think I understand the point
you were getting at, and it's not valid. If something !==FALSE, then TRUE is
one of the values it may be === to -- but so are all the integers, all the
floating numbers, all the strings, all possible objects,
In other words, if $x!==FALSE, it *might* be ===TRUE, but it *might* also be
===0, ===1, ===1.0 (not the same as 1!), ===hello world, etc.
The *test* *itself*, however, would obey that rule -- that the *test* returns a
Boolean value says nothing about the types of its operands.
if !== evaluates an integer 0 to TRUE, so should ===
Neither of them can evaluate an integer 0 to TRUE, as 0 and TRUE are different
types. You're confusing how these operators evaluate their operands with the
resulting value of the test: the === and !== operators will both evaluate an
integer 0 as 0 -- it's the result of the test that will be strictly either TRUE
or FALSE. (As it happens, 0 and FALSE also give different values when evaluated
by ==/!=, so you'd have the same conceptual problem with those operators).
, it
can't be true and still return a false value. The !== and ===
operators work differently, they should be complimentary.
No, they work exactly the same. Both of them *first* look at the types of the
two values, and *if and only if* the types are the same are the values compared.
So: 0!==FALSE will succeed immediately, returning TRUE, because the types differ
and: 0===FALSE will fail immediately, returning FALSE, because the types differ
which are as you expected the complementary Boolean values.
*However*:
1!==FALSE returns TRUE by the same logic, and
1===TRUE returns the complementary FALSE
Immediately, then, you can see that we have two values that are both !==FALSE,
and yet neither of them is the value TRUE.
I'm afraid I've gone on at some length here, but I felt throughout this thread
that you really hadn't grasped the underlying conceptual point, and I hope some
of my examples may have helped illuminate it for you.
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] odd behavior of stripos() with === operator *LAST POST*
Logic dictates that if something evaluates to NOT FALSE it
must be TRUE.
In a situation where you are only dealing with boolean values, that above
statement would be correct. In this case it is not.
int stripos ( string haystack, string needle [, int offset] )
What you are missing here is the fact that this function is designed to tell
you the position of the needle in your haystack, thus it returns an integer
value unless the string is not found.
Since 0 is a valid position and 0 does not evaluate to TRUE, you cannot
check for a TRUE condition. You must check for NOT FALSE.
I think the way you are using this function is to simply see if the needle
is contained within the haystack.
function found_in_string($haystack, $needle) {
$retval = FALSE;
if (stripos($haystack, $needle) !== FALSE) {
$retval = TRUE;
}
return $retval;
}
This function would return only TRUE or FALSE, thus you could conclude that
if the return value is NOT FALSE it _must_ be TRUE.
I hope that helps clarify a bit.
-B
-Original Message-
From: Ford, Mike [mailto:[EMAIL PROTECTED]
Sent: Friday, November 17, 2006 7:15 AM
To: Michael
Cc: php-general@lists.php.net
Subject: RE: [PHP] odd behavior of stripos() with === operator *LAST POST*
On 17 November 2006 09:55, Michael wrote:
This will be my last post on this thread of discussion.
Thanks to all who replied, I have it figured out.
I guess my only problem with the way the !== and ===
operators work in this situation is this:
Logic dictates that if something evaluates to NOT FALSE it
must be TRUE.
Um, yes, but it's the *test* that's evaluating to NOT FALSE (and obeys
this rule), which says nothing about the actual values involved in the
test. Even with the != operator you can demonstrate this point:
$x = yes;
if ($x!=FALSE) { echo \$x must be TRUE }
will display the message, even though $x contains the string yes
(because the string yes in a Boolean context evaluates to TRUE).
if !== evaluates to TRUE then === should also under the same
conditions (all other things being equal)
I don't think that's quite what you meant, but I think I understand the
point you were getting at, and it's not valid. If something !==FALSE,
then TRUE is one of the values it may be === to -- but so are all the
integers, all the floating numbers, all the strings, all possible objects,
In other words, if $x!==FALSE, it *might* be ===TRUE, but it *might* also
be ===0, ===1, ===1.0 (not the same as 1!), ===hello world, etc.
The *test* *itself*, however, would obey that rule -- that the *test*
returns a Boolean value says nothing about the types of its operands.
if !== evaluates an integer 0 to TRUE, so should ===
Neither of them can evaluate an integer 0 to TRUE, as 0 and TRUE are
different types. You're confusing how these operators evaluate their
operands with the resulting value of the test: the === and !== operators
will both evaluate an integer 0 as 0 -- it's the result of the test that
will be strictly either TRUE or FALSE. (As it happens, 0 and FALSE also
give different values when evaluated by ==/!=, so you'd have the same
conceptual problem with those operators).
, it
can't be true and still return a false value. The !== and ===
operators work differently, they should be complimentary.
No, they work exactly the same. Both of them *first* look at the types of
the two values, and *if and only if* the types are the same are the values
compared.
So: 0!==FALSE will succeed immediately, returning TRUE, because the types
differ
and: 0===FALSE will fail immediately, returning FALSE, because the types
differ
which are as you expected the complementary Boolean values.
*However*:
1!==FALSE returns TRUE by the same logic, and
1===TRUE returns the complementary FALSE
Immediately, then, you can see that we have two values that are both
!==FALSE, and yet neither of them is the value TRUE.
I'm afraid I've gone on at some length here, but I felt throughout this
thread that you really hadn't grasped the underlying conceptual point, and
I hope some of my examples may have helped illuminate it for you.
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net
Re: [PHP] odd behavior of stripos() with === operator *LAST POST*
On Fri, 2006-11-17 at 02:54 -0700, Michael wrote:
This will be my last post on this thread of discussion.
Thanks to all who replied, I have it figured out.
I guess my only problem with the way the !== and === operators work in this
situation is this:
Logic dictates that if something evaluates to NOT FALSE it must be TRUE.
Regardless of the type, regardless of the species, breed, flavor etc.
Sure logic dictates that if a return type is confined to the boolean set
then if it is not false it must be true; however, strpos() may return a
value from the set of booleans or a value from the set of integers. As
such, it can have many more return values than only 2.
if !== evaluates to TRUE then === should also under the same conditions (all
other things being equal)
Nope. There are two conditions checkeck when using !== and ===. One
check is the type, the other check is the value. This leaves 4 possible
scenarios:
true - if an only if the type an the value are the same
false - if the type is not the same
false - if the value is not the same
false - if the type and value are not the same
if !== evaluates an integer 0 to TRUE, so should ===, it can't be true and
still return a false value.
An integer 0 is not evaluated to true, a comparison to see if an value
is exactly equal to the integer 0 may return true.
The !== and === operators work differently, they should be
complimentary.
Actually they work the same... I'll demonstrate:
?php
function equals_equals_equals( $value1, $value2 )
{
if( get_type( $value1 ) == get_type( $value2 )
$value1 == $value2 )
{
return true;
}
return false;
}
function not_equals_equals( $value1, $value2 )
{
return !equals_equals_equals( $value1, $value2 );
}
?
So there you have it. The implementation of not_equals_equals() uses
the ! operator on the equals_equals_equals() function and this will give
you the same behaviour as your currently experiencing and having trouble
swallowing.
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior of stripos() with === operator *LAST POST*
Robert Cummings wrote:
On Fri, 2006-11-17 at 02:54 -0700, Michael wrote:
This will be my last post on this thread of discussion.
Thanks to all who replied, I have it figured out.
I guess my only problem with the way the !== and === operators work in this
situation is this:
Logic dictates that if something evaluates to NOT FALSE it must be TRUE.
Regardless of the type, regardless of the species, breed, flavor etc.
Sure logic dictates that if a return type is confined to the boolean set
then if it is not false it must be true; however, strpos() may return a
value from the set of booleans or a value from the set of integers. As
liar liar pants on fire. just to confuse matters (the OP deserves it given the
length of the thread):
strpos() may return a boolean false or a value from the set of integers - it
will never
ever return true (unless you hack the php source)
friday afternoon nitpicking - which is sometimes referred to as 'ant-***ing'
where I come from ;-)
such, it can have many more return values than only 2.
if !== evaluates to TRUE then === should also under the same conditions (all
other things being equal)
Nope. There are two conditions checkeck when using !== and ===. One
check is the type, the other check is the value. This leaves 4 possible
scenarios:
true - if an only if the type an the value are the same
false - if the type is not the same
false - if the value is not the same
false - if the type and value are not the same
if !== evaluates an integer 0 to TRUE, so should ===, it can't be true and
still return a false value.
An integer 0 is not evaluated to true, a comparison to see if an value
is exactly equal to the integer 0 may return true.
The !== and === operators work differently, they should be
complimentary.
Actually they work the same... I'll demonstrate:
?php
function equals_equals_equals( $value1, $value2 )
{
if( get_type( $value1 ) == get_type( $value2 )
$value1 == $value2 )
{
return true;
}
return false;
}
function not_equals_equals( $value1, $value2 )
{
return !equals_equals_equals( $value1, $value2 );
}
?
So there you have it. The implementation of not_equals_equals() uses
the ! operator on the equals_equals_equals() function and this will give
you the same behaviour as your currently experiencing and having trouble
swallowing.
Cheers,
Rob.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior of stripos() with === operator *LAST POST*
On Fri, 2006-11-17 at 17:29 +0100, Jochem Maas wrote: Robert Cummings wrote: On Fri, 2006-11-17 at 02:54 -0700, Michael wrote: This will be my last post on this thread of discussion. Thanks to all who replied, I have it figured out. I guess my only problem with the way the !== and === operators work in this situation is this: Logic dictates that if something evaluates to NOT FALSE it must be TRUE. Regardless of the type, regardless of the species, breed, flavor etc. Sure logic dictates that if a return type is confined to the boolean set then if it is not false it must be true; however, strpos() may return a value from the set of booleans or a value from the set of integers. As liar liar pants on fire. just to confuse matters (the OP deserves it given the length of the thread): strpos() may return a boolean false or a value from the set of integers - it will never ever return true (unless you hack the php source) Where's my baseball bat... ;) Anyways, if you re-read the above I wrote strpos() may return a value from the set of booleans or a value from the set of integers I didn't say WHICH value it would return from the set of booleans *PTTHTHTHTHTTHTT* *nyah nyah* :D Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior of stripos() with === operator *LAST POST*
Robert Cummings wrote: On Fri, 2006-11-17 at 17:29 +0100, Jochem Maas wrote: Robert Cummings wrote: On Fri, 2006-11-17 at 02:54 -0700, Michael wrote: This will be my last post on this thread of discussion. Thanks to all who replied, I have it figured out. I guess my only problem with the way the !== and === operators work in this situation is this: Logic dictates that if something evaluates to NOT FALSE it must be TRUE. Regardless of the type, regardless of the species, breed, flavor etc. Sure logic dictates that if a return type is confined to the boolean set then if it is not false it must be true; however, strpos() may return a value from the set of booleans or a value from the set of integers. As liar liar pants on fire. just to confuse matters (the OP deserves it given the length of the thread): strpos() may return a boolean false or a value from the set of integers - it will never ever return true (unless you hack the php source) Where's my baseball bat... ;) Anyways, if you re-read the above I wrote strpos() may return a value from the set of booleans or a value from the set of integers I didn't say WHICH value it would return from the set of booleans *PTTHTHTHTHTTHTT* *nyah nyah* :D indeeed you didn't say which - thereby implying (or at least allowing for people to assume) that any value in the set of booleans could be returned. which is not true. but then this is the friday freakshow and you and I both know what we're talking about so no harm done ;-) have a good weekend! PS - you swing like a five year old ... girl :-P Cheers, Rob. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior of stripos() with === operator *LAST POST*
At 2:54 AM -0700 11/17/06, Michael wrote: Logic dictates that if something evaluates to NOT FALSE it must be TRUE. Regardless of the type, regardless of the species, breed, flavor etc. Not true -- it depends upon your reference/environment. For example, NULL is neither true nor false in MySQL. So, the result in a MySQL test could be both NOT FALSE and NOT TRUE. tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior of stripos() with === operator *LAST POST*
Ok, just to shut you all up, I managed to convince the OP earlier today, but it never made it to the list... Michael wrote: At 02:58 AM 11/17/2006 , Stut wrote: Michael wrote: This will be my last post on this thread of discussion. Thanks to all who replied, I have it figured out. I guess my only problem with the way the !== and === operators work in this situation is this: Logic dictates that if something evaluates to NOT FALSE it must be TRUE. Regardless of the type, regardless of the species, breed, flavor etc. if !== evaluates to TRUE then === should also under the same conditions (all other things being equal) if !== evaluates an integer 0 to TRUE, so should ===, it can't be true and still return a false value. The !== and === operators work differently, they should be complimentary. Sorry if all this has inconvenienced anyone. Ok, off-list because it will start to annoy people. Your basic misunderstanding is that === is the opposite of !== which it's not. As I've said in previous emails... (INTEGER === true) will always be false because the types don't match (INTEGER !== true) will always be true because the types don't match (INTEGER === false) will always be false because the types don't match (INTEGER === true) will always be false because the types don't match The actual value of the INTEGER does not matter. But the basic thing to get clear in your head is that === and !== are not opposites in the same way that == and != are. Does that make it clearer? -Stut OK I lied, that wasn't my last post , sorry. *lightbulb* Stut, thanks for your help, my thinking that !== and === are opposites is exactly the problem :) I WAS thinking of them as being like != and ==. the stick worked I think :) I finally get it. Thanks again. Cheers, Michael -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] odd behavior of stripos() with === operator *LAST POST*
On 17 November 2006 16:50, Stut wrote: Your basic misunderstanding is that === is the opposite of !== which it's not. Complete rubbish -- it so absolutely is! If $a===$b, then !($a===$b) is the same as $a!==$b, QED. (INTEGER === true) will always be false because the types don't match (INTEGER !== true) will always be true because the types don't match (INTEGER === false) will always be false because the types don't match (INTEGER === true) will always be false because the types don't match Well, you haven't covered all bases there, you've got INTEGER===true in twice! Try this: (integer)===TRUE -- is always FALSE (integer)!==TRUE -- is always TRUE (integer)===FALSE -- is always FALSE (integer)!==FALSE -- is always TRUE Looks seriously like two sets of complementary results there to me. The actual value of the INTEGER does not matter. True. But the basic thing to get clear in your head is that === and !== are not opposites in the same way that == and != are. False, false, false, and a thousand times false. If $a===$b returns TRUE, then $a!==$b returns FALSE; and if $a===$b returns FALSE, then $a!==$b returns TRUE. I don't know how much more opposite you can get. Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] odd behavior of stripos() with === operator
HEllo all,
After pulling my hair out for several hours trying to figure out why my code
wasn't working I built this little test and ran it, the results are interesting
in the least, and to me, surprising. It is possible that I have done something
wrong, but I checked and rechecked this in the documentation.
It appears there is either a problem with the === operator (or my brain...)
If you don't mind, I'd like to see what you all think.
I am running php 5.2.0 on a linux redhat 9 box with Apache 2.2 (the php 5.2.0
install is brand new, perhaps I set it up wrong?)
anyway here is the code I wrote, and the output from it...
$found = stripos(abcdefg, abcdefg);
echo found = stripos(\abcdefg\, \abcdefg\);\n
echo The value of found is = : $found\n
// 1a) --- needle was found in haystack THIS SHOULD BE
if ( $found !== FALSE ) {
echo found does not equal FALSE\n
}
// 1b) --- needle was found in haystack THIS SHOULD ALSO BE
if ($found === TRUE ) {
echo found is equal to TRUE\n
}
//1c) --- needle was NOT found in haystack THIS SHOULD NOT BE
if ( $found === FALSE ) {
echo found is equal to FALSE\n
}
//1d) --- needle was NOT found in haystack THIS ALSO SHOULD NOT BE
if ($found !== TRUE ) {
echo found does not equal TRUE\n
}
$found = stripos(abcdefg, tuvwxyz);
echo \$found = stripos(\abcdefg\, \tuvwxyz\);br\n
echo The value of found is = : $found\n
//2a) --- needle was found in haystack THIS SHOULD NOT BE
if ( $found !== FALSE ) {
echo found does not equal FALSE\n
}
//2b) --- needle was found in haystack THIS ALSO SHOULD NOT BE
if ($found === TRUE ) {
echo found is equal to TRUE\n
}
//2c) --- needle was NOT found in haystack THIS SHOULD BE
if ( $found === FALSE ) {
echo found is equal to FALSE\n
}
//2d) --- needle was NOT found in haystack THIS SHOULD ALSO BE
if ($found !== TRUE ) {
echo found does not equal TRUE\n
}
the output:
$found = stripos(abcdefg, abcdefg);
The value of found is = : 0
found does not equal FALSE //this is from section 1a) of the code
found does not equal TRUE//this is from section 1d) of the code
// I expected the code from 1b) to be executed
$found = stripos(abcdefg, tuvwxyz);
The value of found is = :
found is equal to FALSE //this is from section 2c) of the code
found does not equal TRUE//this is from section 2d) of the code
I have underlined the output I am interested in... How can the variable $found
be both TRUE and FALSE at the same time?
Anyone who can provide me some insight on this, please enlighten me.
If my code is correct, then this behavior of the === operator is
counter-intuitive, it was my understanding that the === and !== operators were
supposed to be used with the output of stripos() for just this situation, but
=== does not appear to recognize that the returned 0 (because the string was
found at index 0) ; whereas the !== does recognize this...
is === buggy? or am I? heh
thoughts? comments?
Thanks all,
Michael
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior of stripos() with === operator
On Fri, 2006-11-17 at 00:24 -0700, Michael wrote:
HEllo all,
After pulling my hair out for several hours trying to figure out why my code
wasn't working I built this little test and ran it, the results are
interesting
in the least, and to me, surprising. It is possible that I have done something
wrong, but I checked and rechecked this in the documentation.
It appears there is either a problem with the === operator (or my brain...)
If you don't mind, I'd like to see what you all think.
I am running php 5.2.0 on a linux redhat 9 box with Apache 2.2 (the php 5.2.0
install is brand new, perhaps I set it up wrong?)
anyway here is the code I wrote, and the output from it...
$found = stripos(abcdefg, abcdefg);
echo found = stripos(\abcdefg\, \abcdefg\);\n
echo The value of found is = : $found\n
// 1a) --- needle was found in haystack THIS SHOULD BE
if ( $found !== FALSE ) {
echo found does not equal FALSE\n
}
// 1b) --- needle was found in haystack THIS SHOULD ALSO BE
if ($found === TRUE ) {
echo found is equal to TRUE\n
}
//1c) --- needle was NOT found in haystack THIS SHOULD NOT BE
if ( $found === FALSE ) {
echo found is equal to FALSE\n
}
//1d) --- needle was NOT found in haystack THIS ALSO SHOULD NOT BE
if ($found !== TRUE ) {
echo found does not equal TRUE\n
}
$found = stripos(abcdefg, tuvwxyz);
echo \$found = stripos(\abcdefg\, \tuvwxyz\);br\n
echo The value of found is = : $found\n
//2a) --- needle was found in haystack THIS SHOULD NOT BE
if ( $found !== FALSE ) {
echo found does not equal FALSE\n
}
//2b) --- needle was found in haystack THIS ALSO SHOULD NOT BE
if ($found === TRUE ) {
echo found is equal to TRUE\n
}
//2c) --- needle was NOT found in haystack THIS SHOULD BE
if ( $found === FALSE ) {
echo found is equal to FALSE\n
}
//2d) --- needle was NOT found in haystack THIS SHOULD ALSO BE
if ($found !== TRUE ) {
echo found does not equal TRUE\n
}
the output:
$found = stripos(abcdefg, abcdefg);
The value of found is = : 0
found does not equal FALSE //this is from section 1a) of the code
found does not equal TRUE//this is from section 1d) of the code
// I expected the code from 1b) to be executed
$found = stripos(abcdefg, tuvwxyz);
The value of found is = :
found is equal to FALSE //this is from section 2c) of the code
found does not equal TRUE//this is from section 2d) of the code
I have underlined the output I am interested in...
You did??? Where?
How can the variable $found be both TRUE and FALSE at the same time?
None of your output above indicates that it is both equal to TRUE and
FALSE at the same time. It does indicate that $found does NOT equal TRUE
and does NOT equal FALSE at the same time and that is because it
returned the integer value 0 which is the location of the string in the
haystack.
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior of stripos() with === operator
At 12:29 AM 11/17/2006 , you wrote: I have underlined the output I am interested in... You did??? Where? Ok, my bad, I sent the mail as plain text instead of styled :P oops How can the variable $found be both TRUE and FALSE at the same time? None of your output above indicates that it is both equal to TRUE and FALSE at the same time. It does indicate that $found does NOT equal TRUE and does NOT equal FALSE at the same time and that is because it returned the integer value 0 which is the location of the string in the haystack. Ok, picking gnits... I should have said NOT true and NOT false at the same time. As for the return of the integer 0.. The documentation indicates that the === and !== operators take this into account in fact there is a specific example in the manual. My point here is that if !== works , why does === not? thanks for responding. Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] odd behavior SOLVED - MORE IMPORTANT
[snip] From the offices of You Ain't Gonna' Beleeeve Dis, Inc. We barked up several trees, but there were no real squirrels. PHP 4.4.1, the version on the server in question, comes with 2 flavors of ini file, the dist and the recommended. I had copied the recommended and renamed it php.ini, which is the one we have been using all day. I am standing in the data center cursing and swearing and the network admin says, Maybe the ini file is hosed somehow. Of course I said that that could not be the case. What could possibly be bad in the text file to cause this kind of behavior? As the afternoon wore on he kept asking if I could water down the ini file because it was the placement of that file that caused the problem. Even when I went the route of changing the environment variable I had problems. I told him that several of the best minds in the world were working on the problem and that the ini file could not be at fault really. I wanted to prove to him that this could not be the case, so I renamed the recommend-php.ini-php.ini.old and copied the dist version which was renamed to php.ini. I moved it to the WINNT folder. I stopped and started IIS. Lo' and behold, the php pages loaded fine, with no 404 error. I made a change to the ini file. It showed up properly in phpinfo(). Dammit he had a smug look on his faced when I departed the data center. Apparently there is something wrong with the 'recommended' version. I will have to compare them to see the differences so that maybe the problem could be isolated so that furture users do not encounter the several hours of frustration that I have encountered. You're all to be praised for your knowledge and insight. Thank you. [/snip] I have found that it is not just with the recommended version. After some more wrangling this morning I have narrowed it down to the doc_root = directive in the ini file. When I moved the 'dist' copy yesterday I had not gone through all of the manual setup steps, so I had not changed doc_root and the extensions directory. I set doc_root as follows; doc_root = E:\sitegrp1 and the behaviors that we discussed yesterday reappeared. Here is the text surrounding the directive ; The root of the PHP pages, used only if nonempty. ; if PHP was not compiled with FORCE_REDIRECT, you SHOULD set doc_root ; if you are running php as a CGI under any web server (other than IIS) ; see documentation for security issues. The alternate is to use the ; cgi.force_redirect configuration below doc_root = Is this the mystical security issues mentioned above (ihaven't located the documentation it refers to at this point)? e:\sitegrp1 has several directories below it, so it is not empty. Anyhow, more to chew on. Thanks again for everyone's help. My php.ini happily resides in c:\php and is properly located and parsed since PHPRC was added to the environment variables (shouldn't this be part of the manual installation steps?). -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] odd behavior
When I expire you will find my hands wrapped tightly around the throat of a Windows network administrator. I had PHP installed on a web server, and all was working OK, save for one small thing. phpinfo() indicated that the path to the php.ini was c:\WINNT, which it was not. So I copy the file from the c:\php directory to the c:\winnt directory and restart IIS. Now, when I click a link to take me to a directory with an index.php I get a 404, not found error. If I refresh the page shows up just fine. So I remove the ini page, start and stop the IIS server, click the link, and no problem...the page is delivered just fine. Has anyone experienced this behavior before, and how do I fix that damned path to the ini? TIA! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior
On Thu, 19 Jan 2006 11:53:04 -0600 Jay Blanchard [EMAIL PROTECTED] wrote: Has anyone experienced this behavior before, and how do I fix that damned path to the ini? TIA! Personally, I'd fix it with a Debian install CD, but that's just me. #;-D Can't help with the Windoze issue - I don't do Windoze. Tried it, didn't like it. Regards, Ozz. pgpUUSTfMwtPU.pgp Description: PGP signature
Re: [PHP] odd behavior
Jay Blanchard wrote: snip and how do I fix http://distrowatch.com/ serious mode I have no idea, I don't do Windows. /serious mode Sucks to be you. ;) -- John C. Nichel IV Programmer/System Admin (ÜberGeek) Dot Com Holdings of Buffalo 716.856.9675 [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior
Ok.. now maybe a constructive answer :) If I recall, PHP on Windows will look for PHP.INI in your Windows system folder (in this case C:\WINNT) first, then in the folder where PHP is installed. Deleting the PHP.INI under WINNT should be fine (sounds like removing that makes things work ok for you). I'd think phpinfo() would show that it's in C:\PHP (or whereever) in that case. If for some reason you need to use PHP.INI in C:\WINNT then let me ask... if you go to http://www.site.com/ (no index.php) on it, is that when you get the 404? Then you say you refresh and it works fine? (does it still read http://www.site.com/ or does it read http://www.site.com/index.php before you hit refresh?) If you get 404, it's the web server telling the browser it can't find the page. So it shouldn't be a permissions issue or anything with PHP.INI (although I'd check to make sure... IIS may not have permissions to read things from C:\WINNT for security reasons... by default at least... or could be that owner/group is now jay or users instead of system or whatever it needs to be for IIS to have access to the PHP.INI file.. I forget the exact permissions). If removing C:\WINNT\PHP.INI doesn't work.. or isn't an option... and permissions look ok... then I'm not sure. But drop a line back when you've messed around with it some more and maybe we can figure it out. -TG = = = Original message = = = When I expire you will find my hands wrapped tightly around the throat of a Windows network administrator. I had PHP installed on a web server, and all was working OK, save for one small thing. phpinfo() indicated that the path to the php.ini was c:\WINNT, which it was not. So I copy the file from the c:\php directory to the c:\winnt directory and restart IIS. Now, when I click a link to take me to a directory with an index.php I get a 404, not found error. If I refresh the page shows up just fine. So I remove the ini page, start and stop the IIS server, click the link, and no problem...the page is delivered just fine. Has anyone experienced this behavior before, and how do I fix that damned path to the ini? TIA! ___ Sent by ePrompter, the premier email notification software. Free download at http://www.ePrompter.com. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior
I use PWS with Windows 98 for learning purposes. I just cut PHP.ini from C:\PHP and paste in %windir% then restart the server. Works fine for me and I can run ASP and PHP for learning. ^^ Regards, Rodolfo Andrade - Original Message - From: Jay Blanchard To: PHP General (E-mail) Sent: Thursday, January 19, 2006 3:53 PM Subject: [PHP] odd behavior When I expire you will find my hands wrapped tightly around the throat of a Windows network administrator. I had PHP installed on a web server, and all was working OK, save for one small thing. phpinfo() indicated that the path to the php.ini was c:\WINNT, which it was not. So I copy the file from the c:\php directory to the c:\winnt directory and restart IIS. Now, when I click a link to take me to a directory with an index.php I get a 404, not found error. If I refresh the page shows up just fine. So I remove the ini page, start and stop the IIS server, click the link, and no problem...the page is delivered just fine. Has anyone experienced this behavior before, and how do I fix that damned path to the ini? TIA! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] odd behavior
[snip] If I recall, PHP on Windows will look for PHP.INI in your Windows system folder (in this case C:\WINNT) first, then in the folder where PHP is installed. Deleting the PHP.INI under WINNT should be fine (sounds like removing that makes things work ok for you). I'd think phpinfo() would show that it's in C:\PHP (or whereever) in that case. [/snip] c:\php is in the path statement, but it does not show it as being there when I remove it from c:\winnt [snip] If for some reason you need to use PHP.INI in C:\WINNT then let me ask... [/snip] Changes in php.ini are not reflected in phpinfo() after an IIS restart (cache cleared). For instance, the extensions folder is c:\php\extensions, the ini reports c:\php4 [snip] if you go to http://www.site.com/ (no index.php) on it, is that when you get the 404? Then you say you refresh and it works fine? (does it still read http://www.site.com/ or does it read http://www.site.com/index.php before you hit refresh?) [/snip] Yes.It still reads http://www.site.com before and after refresh. [snip] If you get 404, it's the web server telling the browser it can't find the page. So it shouldn't be a permissions issue or anything with PHP.INI (although I'd check to make sure... IIS may not have permissions to read things from C:\WINNT for security reasons... by default at least... or could be that owner/group is now jay or users instead of system or whatever it needs to be for IIS to have access to the PHP.INI file.. I forget the exact permissions). [/snip] I'll check it. [snip] If removing C:\WINNT\PHP.INI doesn't work.. or isn't an option... and permissions look ok... then I'm not sure. But drop a line back when you've messed around with it some more and maybe we can figure it out. [/snip] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior
On Thu, January 19, 2006 11:53 am, Jay Blanchard wrote: I had PHP installed on a web server, and all was working OK, save for one small thing. phpinfo() indicated that the path to the php.ini was c:\WINNT, which it was not. So I copy the file from the c:\php directory to the c:\winnt directory and restart IIS. Now, when I click a link to take me to a directory with an index.php I get a 404, not found error. If I refresh the page shows up just fine. So I remove the ini page, start and stop the IIS server, click the link, and no problem...the page is delivered just fine. Has anyone experienced this behavior before, and how do I fix that damned path to the ini? TIA! How you fix the path to php.ini is what you did in the first place, except you shouldn't leave behind the c:\php\php.ini to confuse yourself some other day. MOVE the file to c:\winnt where PHP thinks it must be. Other Options: Re-compile PHP from scratch to choose a different path for php.ini Use that new-fangled Apache directive to tell Apache where to find php.ini -- This implies dumping IIS and using Apache, which you should do anyway :-) Meanwhile, back at the ranch, your question SHOULD be: How do I get IIS to not return 404 for the first hit on a URL, then the correct content on subsequent hits? Standard Windows Debugging 101: #1 Re-boot the whole machine and pray. #2 Re-install the entire OS and all software. #3 Switch to Linux. The first two steps are what Microsoft always tells me to do. :-) Sorry. Best I can do for you... PS I suspect that in this case, some sort of brain-dead IIS/DNS/MS-OS cache is screwing you up and a re-boot (#1) actually WILL solve the problem. This is, however, only a guess. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] odd behavior
On Thu, January 19, 2006 12:31 pm, Jay Blanchard wrote: [snip] If I recall, PHP on Windows will look for PHP.INI in your Windows system folder (in this case C:\WINNT) first, then in the folder where PHP is installed. Deleting the PHP.INI under WINNT should be fine (sounds like removing that makes things work ok for you). I'd think phpinfo() would show that it's in C:\PHP (or whereever) in that case. [/snip] Almost for sure, this is just plain wrong. It is maybe correct for DLLs, with the caveat that PHP will also look in the extensions directory in php.ini, assuming you get php.ini loaded in the first place. c:\php is in the path statement, but it does not show it as being there when I remove it from c:\winnt [snip] PHP doesn't consider 'path' at all when looking for php.ini, almost for sure. It's a constant compiled into the software, essentially, except for the new-fangled Apache directive to change it. If for some reason you need to use PHP.INI in C:\WINNT then let me ask... [/snip] Changes in php.ini are not reflected in phpinfo() after an IIS restart (cache cleared). For instance, the extensions folder is c:\php\extensions, the ini reports c:\php4 Changes in php.ini are irrelevant until you get php.ini loaded by putting it into c:\winnt where PHP is looking. Your 404 problem is entirely separate and distinct from this issue. Solve them separately. php.ini problem is easily solved. 404, you're on your own. [snip] if you go to http://www.site.com/ (no index.php) on it, is that when you get the 404? Then you say you refresh and it works fine? (does it still read http://www.site.com/ or does it read http://www.site.com/index.php before you hit refresh?) [/snip] This is probably dependent on web-server configuration. Or, at least, it is possible to configure Apache in such a way that it will actually force the user to be re-directed to the DocumentIndex, I think. Or perhaps naive inexperienced Apache users do this as a work-around since they don't understand DocumentIndex. I got no idea how IIS handles any of the DocumentIndex-like stuff. Yes.It still reads http://www.site.com before and after refresh. [snip] If you get 404, it's the web server telling the browser it can't find the page. So it shouldn't be a permissions issue or anything with PHP.INI (although I'd check to make sure... IIS may not have permissions to read things from C:\WINNT for security reasons... by default at least... or could be that owner/group is now jay or users instead of system or whatever it needs to be for IIS to have access to the PHP.INI file.. I forget the exact permissions). [/snip] If it doesn't have permissions the first page hit, it won't have permissions the second time. Seems unlikely to be the source of the problem... -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] odd behavior SOLVED
[snip] ...lots of valuable information [/snip] From the offices of You Ain't Gonna' Beleeeve Dis, Inc. We barked up several trees, but there were no real squirrels. PHP 4.4.1, the version on the server in question, comes with 2 flavors of ini file, the dist and the recommended. I had copied the recommended and renamed it php.ini, which is the one we have been using all day. I am standing in the data center cursing and swearing and the network admin says, Maybe the ini file is hosed somehow. Of course I said that that could not be the case. What could possibly be bad in the text file to cause this kind of behavior? As the afternoon wore on he kept asking if I could water down the ini file because it was the placement of that file that caused the problem. Even when I went the route of changing the environment variable I had problems. I told him that several of the best minds in the world were working on the problem and that the ini file could not be at fault really. I wanted to prove to him that this could not be the case, so I renamed the recommend-php.ini-php.ini.old and copied the dist version which was renamed to php.ini. I moved it to the WINNT folder. I stopped and started IIS. Lo' and behold, the php pages loaded fine, with no 404 error. I made a change to the ini file. It showed up properly in phpinfo(). Dammit he had a smug look on his faced when I departed the data center. Apparently there is something wrong with the 'recommended' version. I will have to compare them to see the differences so that maybe the problem could be isolated so that furture users do not encounter the several hours of frustration that I have encountered. You're all to be praised for your knowledge and insight. Thank you. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Odd behavior with unset, array indexes, and types
Curt Zirzow wrote: To simplify things: $a[2] = '1'; $k = (double)2; echo isset($a[$k]); unset($a[$k]); echo isset($a[$k]); echo - expect 1\n; Result: 11 - expect 1 Yeah, my version was just a wee bit verbose. :) It's the behavior that is specific to unset() that I'm puzzled about. The problem is, array hash's and indexes must be either integer or string as noted in the manual, so technically it really isn't a bug even though it appears to behave like one. Yeah, I agree. Personally, IMHO if there is a problem the problem is with isset(), not unset(). IMHO isset($var[(double) 2]) should return false at the least. Ideally I think any attempt to use a double as an array index should produce a warning (or notice), just like trying to use a resource or object does (Illegal offset type). Although if the error didn't mention double specifically it'd probably confuse the heck out of people. I would have to agree that there does seem to be inconsistencies between isset and unset, So perhaps mabey submiting a Feature Request showing how close php seems to supporting (floats) as indexes. Probably a good idea. or to make the above not look too silly: $k = (int) ceil(3/4); That's what I ended up doing. I lost a couple of hours and quite a bit of hair first, though. :) Thanks for the feedback... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Odd behavior with unset, array indexes, and types
Just noticed this today. The following script:
quote
$a = 2;
$b = ceil(3 / 2);
if ($a == $b) {
print \$a and \$b are the same.\n;
}
$foo[$a] = '2';
if (isset($foo[$b])) {
print \$foo[\$b] is set.\n;
}
unset($foo[$b]);
print_r($foo);
/quote
Results in this output:
quote
$a and $b are the same.
$foo[$b] is set.
Array
(
[2] = 2
)
/quote
ceil() returns a variable of type double. In the above script I expected $foo to
become an empty array after calling unset(). But it seems that unset() will not
remove an array element when you refer to its key using a double, although isset()
will return true when referenced the same way. If I cast $b to either an int or a
string, the unset call works. Am I just missing the portion of the manual that
documents this behavior, or is this a bug? Just thought I'd see if anyone had run
across this before...TIA
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Odd behavior with unset, array indexes, and types
On Thu, 17 Jun 2004 16:52:32 -0500, Michael Sims [EMAIL PROTECTED] wrote: ceil() returns a variable of type double. In the above script I expected $foo to become an empty array after calling unset(). But it seems that unset() will not remove an array element when you refer to its key using a double, although isset() will return true when referenced the same way. If I cast $b to either an int or a string, the unset call works. Am I just missing the portion of the manual that documents this behavior, or is this a bug? Just thought I'd see if anyone had run across this before...TIA == does not check type in php. Hence, 2.0 == 2 == '2'. However, array indexes are type specific, so $a[2] != $a['2']. Use === for type specific checking, i.e.: echo 2 === '2'; will echo 0. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Odd behavior with unset, array indexes, and types
Thomas Goyne wrote:
On Thu, 17 Jun 2004 16:52:32 -0500, Michael Sims
[EMAIL PROTECTED] wrote:
ceil() returns a variable of type double. In the above script I
expected $foo to become an empty array after calling unset(). But
it seems that unset() will not remove an array element when you
refer to its key using a double, although isset() will return true
when referenced the same way. If I cast $b to either an int or a
string, the unset call works. Am I just missing the portion of the
manual that documents this behavior, or is this a bug? Just thought
I'd see if anyone had run across this before...TIA
== does not check type in php.
Yes, I'm aware of that. That's not what my post was about.
However,
array indexes are type specific, so $a[2] != $a['2'].
That's incorrect (at least with PHP 4.3.7). PHP will happily cast your array index
and compare it without regard to type in some cases, as a simple test illustrates:
quote
$a[2] = 1;
if ($a[2] == $a['2']) {
print Arrays indexes are not type specific, at least not in all cases.\n;
}
if ($a[2] == $a[(double) 2]) {
print Integers and doubles compare, even when using '=='.\n;
}
if (isset($a[(double) 2])) {
print isset() doesn't have a problem casting the array index.\n;
}
unset($a[(double) 2]);
if (isset($a[2])) {
print It appears that only unset() has a problem with this.\n;
}
/quote
generates:
quote
Arrays indexes are not type specific, at least not in all cases.
Integers and doubles compare, even when using '=='.
isset() doesn't have a problem casting the array index.
It appears that only unset() has a problem with this.
/quote
It's the behavior that is specific to unset() that I'm puzzled about.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Odd behavior with unset, array indexes, and types
* Thus wrote Michael Sims:
Thomas Goyne wrote:
On Thu, 17 Jun 2004 16:52:32 -0500, Michael Sims
[EMAIL PROTECTED] wrote:
ceil() returns a variable of type double. In the above script I
expected $foo to become an empty array after calling unset(). But
However,
array indexes are type specific, so $a[2] != $a['2'].
That's incorrect (at least with PHP 4.3.7). PHP will happily cast your array index
and compare it without regard to type in some cases, as a simple test illustrates:
quote
$a[2] = 1;
if ($a[2] == $a['2']) {
print Arrays indexes are not type specific, at least not in all cases.\n;
}
if ($a[2] == $a[(double) 2]) {
print Integers and doubles compare, even when using '=='.\n;
}
To simplify things:
$a[2] = '1';
$k = (double)2;
echo isset($a[$k]);
unset($a[$k]);
echo isset($a[$k]);
echo - expect 1\n;
Result:
11 - expect 1
It's the behavior that is specific to unset() that I'm puzzled about.
The problem is, array hash's and indexes must be either integer or
string as noted in the manual, so technically it really isn't a bug
even though it appears to behave like one.
I would have to agree that there does seem to be inconsistencies
between isset and unset, So perhaps mabey submiting a Feature
Request showing how close php seems to supporting (floats) as indexes.
You're alternative would be to cast your double to a int or string:
$k = (int)(double)2;
or to make the above not look too silly:
$k = (int) ceil(3/4);
HTH,
Curt
--
First, let me assure you that this is not one of those shady pyramid schemes
you've been hearing about. No, sir. Our model is the trapezoid!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior
At 30.04.2002 18:29, you wrote:
When I run this the first time, file.txt contains value of 30. Then I add 15
to it with following script and file now contains value of 45. I look at
file.txt after write and it does indeed contain number 45. But when I run
script 24 hours later via cron job, it still thinks file.txt is holding
number 30. Is $file somehow retaining value of 30 and not getting new value
of 45 when script runs second time? What is it called when this happens?
?php
$file = file('/usr/home/xyz/file.txt'); //file.txt contains value of 30
$number = 15;
$newnumber = $file + $number; //$newnumber now is 45
$fp = fopen('/usr/home/xyz/file.txt','w');
fputs($fp,$newnumber); // write value 45 to file.txt
fclose($fp);
?
Thanks
Craig
[EMAIL PROTECTED]
Hi Craig,
you read the file in an array, therfore you have to add your number to
$file[0];
Also look, if the rights are set correct.
BTW I just tried it, and all errors appeared.
HTH Oliver
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior
check clearstatcache()
Charles Killmer
-- Original Message --
From: Craig Westerman [EMAIL PROTECTED]
Date: Tue, 30 Apr 2002 18:29:37 -0500
When I run this the first time, file.txt contains value of 30. Then I add 15
to it with following script and file now contains value of 45. I look at
file.txt after write and it does indeed contain number 45. But when I run
script 24 hours later via cron job, it still thinks file.txt is holding
number 30. Is $file somehow retaining value of 30 and not getting new value
of 45 when script runs second time? What is it called when this happens?
?php
$file = file('/usr/home/xyz/file.txt'); //file.txt contains value of 30
$number = 15;
$newnumber = $file + $number; //$newnumber now is 45
$fp = fopen('/usr/home/xyz/file.txt','w');
fputs($fp,$newnumber); // write value 45 to file.txt
fclose($fp);
?
Thanks
Craig
[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] odd behavior
When I run this the first time, file.txt contains value of 30. Then I add 15
to it with following script and file now contains value of 45. I look at
file.txt after write and it does indeed contain number 45. But when I run
script 24 hours later via cron job, it still thinks file.txt is holding
number 30. Is $file somehow retaining value of 30 and not getting new value
of 45 when script runs second time? What is it called when this happens?
?php
$file = file('/usr/home/xyz/file.txt'); //file.txt contains value of 30
$number = 15;
$newnumber = $file + $number; //$newnumber now is 45
$fp = fopen('/usr/home/xyz/file.txt','w');
fputs($fp,$newnumber); // write value 45 to file.txt
fclose($fp);
?
Thanks
Craig
[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] odd behavior
Sure you got your permissions set right?
On Tuesday 30 April 2002 16:29 pm, you wrote:
When I run this the first time, file.txt contains value of 30. Then I add
15 to it with following script and file now contains value of 45. I look at
file.txt after write and it does indeed contain number 45. But when I run
script 24 hours later via cron job, it still thinks file.txt is holding
number 30. Is $file somehow retaining value of 30 and not getting new value
of 45 when script runs second time? What is it called when this happens?
?php
$file = file('/usr/home/xyz/file.txt'); //file.txt contains value of 30
$number = 15;
$newnumber = $file + $number; //$newnumber now is 45
$fp = fopen('/usr/home/xyz/file.txt','w');
fputs($fp,$newnumber); // write value 45 to file.txt
fclose($fp);
?
Thanks
Craig
[EMAIL PROTECTED]
--
God is a comedian playing to an audience too afraid to laugh.
Voltaire
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] odd behavior
Hi,
I have been trying to create a directory and a file in it on my server, but my
code is not working fine.
?php
$arquivo = fopen(publico/diretorio.txt,r);
$cont = fread($arquivo, 5);
$cont++;
fclose ($arquivo);
$arquivo = fopen (publico/diretorio.txt,w+);
fwrite ($arquivo, $cont);
fclose ($arquivo);
setcookie(cont, $cont);
$diretorio = d.$cont;
if (!is_dir(publico/$diretorio)){
$dirteste = mkdir(publico/$diretorio,0777);}
if ($textfile = fopen(publico/$diretorio/index.html, w+)){
fputs($textfile,ob_get_contents());
fclose($textfile);
chmod(publico/$diretorio/index.html, 0755);}
ob_end_flush();
?
This was working fine and then stoped. Does anybody know what happened?
I have permission to write but I'm receving the following message:
Warning: fopen(publico/d6/index.html,w+) - Permission denied in
/home/a0010927/public_html/index.php on line 56
