[PHP] Enabling the chroot() function in PHP 5.4
Hi All, Does anybody know how to enable the chroot() function in PHP 5.4? It was easy in PHP 5.3 as long as you were building the CLI by itself. In the PHP 5.4 configure script there is a new PHP_BINARIES variable being used instead of setting PHP_SAPI=cli and thus the "#define ENABLE_CHROOT_FUNC 1" is never written to the output file. I have been able to manually enable it by adding the define to the main/php_config.h after running configure. The issue seems to be a line: if test "program" = "program". This comparison being true is what causes the configure script to add "cli" to the PHP_BINARIES variable instead of setting the PHP_SAPI variable. The other prerequisites (HAVE_CHROOT and ZTS) are all at the required settings. It is only the ENABLE_CHROOT_FUNC which is causing the function to not be compiled into the resulting binary. Any information or explanation would be very helpful. For the record, I know what the chroot() function does and does not do. I am experimenting with using chroot() to isolate an already running script to a particular subset of the filesystem for file operations. -- - Aaron -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP is Zero
Hi all,
I want to start a discussion about a PHP behaviour that drives me crazy for
years. For the beginning I would like you to guess what the result of the
following snippet will be:
var_dump('PHP' == 0);
I know the difference of == and === but the result was unexcpected for me. And
I hope it is also for you. The result is simply "true". Why is it true? I guess
this happens because of the conversion from 'PHP' to a number which will be 0
in PHP. And of course 0 equals 0. There are several points that I just want to
drop into this mailinglist to discuss about:
1. Why? :)
2. Why is PHP converting the String into a Number instead of converting the
Number into a String? (If my guess concerning the behaviour is correct)
3. Why is PHP throwing data away which has the developer explicit given to the
interpreter?
4. Why does var_dump(0 == 'PHP'); has the same result as the snippet above?
This meens that the equal operator is not explictly implemented in the string
or integer?
5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739 where I also
had the same problems because "8315e839da08e2a7afe6dd12ec58245d" was converted
into float(INF) by throwing everything starting from "da08.." away.
I am using PHP since the year 2000. This means I have 13 years of experience in
PHP and I really would like you to NOT just answer "works as designed". I know
it works as designed but I want to discuss the design. Also I know that the
"fuzzy" behaviour of type conversion is a main feature of PHP. I guess this is
one point which makes PHP that successfull. But - in my opinion - the described
behaviour is to fuzzy and just confuses developers.
Best Regards
Daniel Buschke
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP is Zero
Sorry missed to post list as well
Hi Daniel,
here is wild goose
i assume you have 3 x =
in your "problem" formulation
which could possibly result in the akward standard C mixup;
the rightmost = first parsed and resulting in an ASSIGMENT to the variable
with that value,
the comes the parsing of == which is the equivalence test, and see; the
variable is
the same since it was just assigned that value; if this theory is correct
you would
get TRUE regardless what number is following :)
/g
- Original Message -
From: "BUSCHKE Daniel"
To:
Sent: Thursday, June 13, 2013 9:59 AM
Subject: [PHP] PHP is Zero
Hi all,
I want to start a discussion about a PHP behaviour that drives me crazy
for years. For the beginning I would like you to guess what the result of
the following snippet will be:
var_dump('PHP' == 0);
I know the difference of == and === but the result was unexcpected for
me. And I hope it is also for you. The result is simply "true". Why is it
true? I guess this happens because of the conversion from 'PHP' to a
number which will be 0 in PHP. And of course 0 equals 0. There are
several points that I just want to drop into this mailinglist to discuss
about:
1. Why? :)
2. Why is PHP converting the String into a Number instead of converting
the Number into a String? (If my guess concerning the behaviour is
correct)
3. Why is PHP throwing data away which has the developer explicit given
to the interpreter?
4. Why does var_dump(0 == 'PHP'); has the same result as the snippet
above? This meens that the equal operator is not explictly implemented in
the string or integer?
5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739 where
I also had the same problems because "8315e839da08e2a7afe6dd12ec58245d"
was converted into float(INF) by throwing everything starting from
"da08.." away.
I am using PHP since the year 2000. This means I have 13 years of
experience in PHP and I really would like you to NOT just answer "works
as designed". I know it works as designed but I want to discuss the
design. Also I know that the "fuzzy" behaviour of type conversion is a
main feature of PHP. I guess this is one point which makes PHP that
successfull. But - in my opinion - the described behaviour is to fuzzy
and just confuses developers.
Best Regards
Daniel Buschke
--
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
AW: [PHP] PHP is Zero
Hi,
I used 2 x =. Using 3 x = would not result in that behaviour because string is
not equal to number. I am fine === here. I explicitly talk about the 2 x =
variant.
BTW:
# php -r 'var_dump("PHP" == 0);'
bool(true)
# php -r 'var_dump("PHP" == 1);'
bool(false)
regards
Daniel
-Ursprüngliche Nachricht-
Von: georg [mailto:georg.chamb...@telia.com]
Gesendet: Donnerstag, 13. Juni 2013 10:35
An: BUSCHKE Daniel
Cc: php-general@lists.php.net
Betreff: Re: [PHP] PHP is Zero
Sorry missed to post list as well
> Hi Daniel,
> here is wild goose
>
> i assume you have 3 x =
> in your "problem" formulation
> which could possibly result in the akward standard C mixup; the
> rightmost = first parsed and resulting in an ASSIGMENT to the variable
> with that value, the comes the parsing of == which is the equivalence
> test, and see; the variable is the same since it was just assigned
> that value; if this theory is correct you would get TRUE regardless
> what number is following :) /g
>
> - Original Message -
> From: "BUSCHKE Daniel"
> To:
> Sent: Thursday, June 13, 2013 9:59 AM
> Subject: [PHP] PHP is Zero
>
>
>> Hi all,
>> I want to start a discussion about a PHP behaviour that drives me
>> crazy for years. For the beginning I would like you to guess what the
>> result of the following snippet will be:
>>
>> var_dump('PHP' == 0);
>>
>> I know the difference of == and === but the result was unexcpected
>> for me. And I hope it is also for you. The result is simply "true".
>> Why is it true? I guess this happens because of the conversion from
>> 'PHP' to a number which will be 0 in PHP. And of course 0 equals 0.
>> There are several points that I just want to drop into this
>> mailinglist to discuss
>> about:
>>
>> 1. Why? :)
>> 2. Why is PHP converting the String into a Number instead of
>> converting the Number into a String? (If my guess concerning the
>> behaviour is
>> correct)
>> 3. Why is PHP throwing data away which has the developer explicit
>> given to the interpreter?
>> 4. Why does var_dump(0 == 'PHP'); has the same result as the snippet
>> above? This meens that the equal operator is not explictly
>> implemented in the string or integer?
>> 5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739
>> where I also had the same problems because "8315e839da08e2a7afe6dd12ec58245d"
>> was converted into float(INF) by throwing everything starting from
>> "da08.." away.
>>
>> I am using PHP since the year 2000. This means I have 13 years of
>> experience in PHP and I really would like you to NOT just answer
>> "works as designed". I know it works as designed but I want to
>> discuss the design. Also I know that the "fuzzy" behaviour of type
>> conversion is a main feature of PHP. I guess this is one point which
>> makes PHP that successfull. But - in my opinion - the described
>> behaviour is to fuzzy and just confuses developers.
>>
>> Best Regards
>> Daniel Buschke
>>
>> --
>> 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] PHP is Zero
On 13/06/13 08:59, BUSCHKE Daniel wrote:
Hi all,
I want to start a discussion about a PHP behaviour that drives me crazy for
years. For the beginning I would like you to guess what the result of the
following snippet will be:
var_dump('PHP' == 0);
I know the difference of == and === but the result was unexcpected for me. And I hope it
is also for you. The result is simply "true". Why is it true? I guess this
happens because of the conversion from 'PHP' to a number which will be 0 in PHP. And of
course 0 equals 0. There are several points that I just want to drop into this
mailinglist to discuss about:
1. Why? :)
42
2. Why is PHP converting the String into a Number instead of converting the
Number into a String? (If my guess concerning the behaviour is correct)
Since PHP is a weakly-typed language, it has to choose one way or the
other. The behaviour *is* predictable if you know what the rule is (I'm
sure the order of conversion is documented somewhere).
3. Why is PHP throwing data away which has the developer explicit given to the
interpreter?
Because PHP is weakly-typed, the developer is not being sufficiently
explicit. Try
php -r 'var_dump(intval('PHP') == 0);'
and
php -r 'var_dump('PHP' == strval(0));'
to see explicit code. Anything less is implicit.
4. Why does var_dump(0 == 'PHP'); has the same result as the snippet above?
This meens that the equal operator is not explictly implemented in the string
or integer?
The rule is consistent: it always converts the string to an integer
whatever the order.
5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739 where I also had the same
problems because "8315e839da08e2a7afe6dd12ec58245d" was converted into float(INF) by
throwing everything starting from "da08.." away.
That's a very different proposition, and probably has more to do with
word size: float is 32-bit, so only the first 32 bits are used and if
anything else is found the conversion falls back to INF. To handle
really big integers like 8315e839da08e2a7afe6dd12ec58245d you probably
need a more specialist library (or language)
I am using PHP since the year 2000. This means I have 13 years of experience in PHP and I really
would like you to NOT just answer "works as designed". I know it works as designed but I
want to discuss the design. Also I know that the "fuzzy" behaviour of type conversion is
a main feature of PHP. I guess this is one point which makes PHP that successfull. But - in my
opinion - the described behaviour is to fuzzy and just confuses developers.
The weak typing *is* a feature of PHP: other languages are more suitable
when you need more enforcement of types: Java, for example.
With all due respect to an experience programmer, years of experience do
not make up for a limited tool set.
Best Regards
Daniel Buschke
Cheers
Pete
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP] PHP is Zero
Hi,
thanks for your answer. Especially the answer "42" made me laughing :)
My "Why" questions should be understand as "Why must it be like that" questions.
>> On 13/06/13 08:59, BUSCHKE Daniel wrote:
>> 5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739 where I
>> also had the same problems because "8315e839da08e2a7afe6dd12ec58245d" was
>> converted into float(INF) by throwing everything starting from "da08.." away.
>>
> That's a very different proposition, and probably has more to do with word
> size: float is 32-bit, so only the first 32 bits are used and if anything
> else is found the conversion falls back to INF. To handle really big integers
> like 8315e839da08e2a7afe6dd12ec58245d you probably need a more specialist
> library (or language)
For me it is not. PHP throws things away during conversion. In my opinion a
language (compiler, interpreter whatever) should not do that. Never ever!
Either it is able to convert the value or it is not.
What about of returning "null" instead of "0" if the conversion is not perfect?
So intval('F') could return NULL and intval('0') could return 0.
Regards
Daniel
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP] PHP is Zero
On 13/06/2013 11:44, BUSCHKE Daniel wrote:
Hi,
thanks for your answer. Especially the answer "42" made me laughing :)
My "Why" questions should be understand as "Why must it be like that" questions.
On 13/06/13 08:59, BUSCHKE Daniel wrote:
5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739 where I also had the same
problems because "8315e839da08e2a7afe6dd12ec58245d" was converted into float(INF) by
throwing everything starting from "da08.." away.
That's a very different proposition, and probably has more to do with word
size: float is 32-bit, so only the first 32 bits are used and if anything else
is found the conversion falls back to INF. To handle really big integers like
8315e839da08e2a7afe6dd12ec58245d you probably need a more specialist library
(or language)
For me it is not. PHP throws things away during conversion. In my opinion a
language (compiler, interpreter whatever) should not do that. Never ever!
Either it is able to convert the value or it is not.
What about of returning "null" instead of "0" if the conversion is not perfect?
So intval('F') could return NULL and intval('0') could return 0.
Regards
Daniel
I think you will have to live with this or use another language for
development - IMO it will never change because of the massive BC break
that would be produced by changing the type juggling behaviour... of
course you could always post an RFC to the dev/internals list if you
want to take this further... good luck with that!
Cheers
Rich
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP] PHP is Zero
On 13/06/13 10:44, BUSCHKE Daniel wrote:
Hi,
thanks for your answer. Especially the answer "42" made me laughing :)
My "Why" questions should be understand as "Why must it be like that" questions.
On 13/06/13 08:59, BUSCHKE Daniel wrote:
5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739 where I also had the same
problems because "8315e839da08e2a7afe6dd12ec58245d" was converted into float(INF) by
throwing everything starting from "da08.." away.
That's a very different proposition, and probably has more to do with word
size: float is 32-bit, so only the first 32 bits are used and if anything else
is found the conversion falls back to INF. To handle really big integers like
8315e839da08e2a7afe6dd12ec58245d you probably need a more specialist library
(or language)
For me it is not. PHP throws things away during conversion. In my opinion a
language (compiler, interpreter whatever) should not do that. Never ever!
Either it is able to convert the value or it is not.
What about of returning "null" instead of "0" if the conversion is not perfect?
So intval('F') could return NULL and intval('0') could return 0.
Regards
Daniel
I've had a bit of a play with your big hex number, and the problem is
much more subtle: floatval("8315e839da08e2a7afe6dd12ec58245d") is
truncated at 8315e839 because it tries to parse it as an exponential
float: floatval("8315e83") becomes 8.315 x 10^86, but 8.315e839 is 8.315
x 10^842 which is (as far as PHP is concerned) an infinitely large number!
So we try replacing that first 'e' with a 'd' (for example) and then
php -r 'var_dump(floatval("8315d839da08e2a7afe6dd12ec58245d"));'
returns
float(8315)
It gives up when it finds a non-numeric character (as the documentation
would tell you)
Perhaps what you need is
php -r 'var_dump(floatval(0x8315e839da08e2a7afe6dd12ec58245d));'
float(1.7424261578436E+38)
In other words, you need to tell the interpreter that you have a number
(in base-16) rather than a string.
A proper strongly-typed language would just tell you that it's nonsense...
Cheers
Pete
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: [PHP] PHP is Zero
Hi, > It gives up when it finds a non-numeric character (as the documentation would > tell you) Why is PHP doing that? I know it works as designed and I know it is documented like this but that does not mean that it is a good feature, does it? So lets talk about the question: Is that behaviour awaited by PHP software developers? Is that really the way PHP should work here? May we should change that?! BTW: I talked to some collegues and friends since my first post. They all guessed that "'PHP' == 0" is false within a few seconds. I think the weak-typed-PHP is a little to weak at this point. Regards Daniel -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: [PHP] PHP is Zero
To be more technical:
If intval('8315e839da08e2a7afe6dd12ec58245d') would return NULL instead of 8315
then PHP would be still weak-typed and the developer could know that the
conversion failed. Good idea? Of course NULL should be transparent in
operations like +. So 0 + NULL should be still 0.
Regards
Daniel
-Ursprüngliche Nachricht-
Von: BUSCHKE Daniel
Gesendet: Donnerstag, 13. Juni 2013 13:28
An: 'Pete Ford'; php-general@lists.php.net
Betreff: AW: AW: [PHP] PHP is Zero
Hi,
> It gives up when it finds a non-numeric character (as the documentation would
> tell you)
Why is PHP doing that? I know it works as designed and I know it is documented
like this but that does not mean that it is a good feature, does it? So lets
talk about the question: Is that behaviour awaited by PHP software developers?
Is that really the way PHP should work here? May we should change that?!
BTW: I talked to some collegues and friends since my first post. They all
guessed that "'PHP' == 0" is false within a few seconds. I think the
weak-typed-PHP is a little to weak at this point.
Regards
Daniel
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP] PHP is Zero
I agree with you that this is a confusing and error-prone behavior, but I
also agree with Richard Gray, I wouldn't try to change this for the same
reason that a "1+1=3" shouldn't be touched if it's "correct" on a huge
amount of existing codebases...
On Thu, Jun 13, 2013 at 8:49 AM, BUSCHKE Daniel <
daniel.busc...@nextiraone.eu> wrote:
> To be more technical:
>
> If intval('8315e839da08e2a7afe6dd12ec58245d') would return NULL instead of
> 8315 then PHP would be still weak-typed and the developer could know that
> the conversion failed. Good idea? Of course NULL should be transparent in
> operations like +. So 0 + NULL should be still 0.
>
> Regards
> Daniel
>
> -Ursprüngliche Nachricht-
> Von: BUSCHKE Daniel
> Gesendet: Donnerstag, 13. Juni 2013 13:28
> An: 'Pete Ford'; php-general@lists.php.net
> Betreff: AW: AW: [PHP] PHP is Zero
>
> Hi,
>
> > It gives up when it finds a non-numeric character (as the documentation
> would tell you)
>
> Why is PHP doing that? I know it works as designed and I know it is
> documented like this but that does not mean that it is a good feature, does
> it? So lets talk about the question: Is that behaviour awaited by PHP
> software developers? Is that really the way PHP should work here? May we
> should change that?!
>
> BTW: I talked to some collegues and friends since my first post. They all
> guessed that "'PHP' == 0" is false within a few seconds. I think the
> weak-typed-PHP is a little to weak at this point.
>
> Regards
> Daniel
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP] PHP is Zero
On 13 Jun 2013, at 12:27, BUSCHKE Daniel wrote: > Hi, > >> It gives up when it finds a non-numeric character (as the documentation >> would tell you) > > Why is PHP doing that? I know it works as designed and I know it is > documented like this but that does not mean that it is a good feature, does > it? So lets talk about the question: Is that behaviour awaited by PHP > software developers? Is that really the way PHP should work here? May we > should change that?! > > BTW: I talked to some collegues and friends since my first post. They all > guessed that "'PHP' == 0" is false within a few seconds. I think the > weak-typed-PHP is a little to weak at this point. I don't know what the actual reasoning is; if you want that I suggest you ask on the internals list, but be careful how you phrase the question. If it's pure curiosity then that's fine, but whether you agree with the reasoning or not it's gone way past the point where it can be changed. My take it that the behaviour is perfectly reasonable. When you compare two different types it has to convert one of them. If you're comparing a string to a number it seems logical to me that the number should be the preferred type, so the string gets converted. What would you expect array(5) == 5 to give you? Would you expect the 5 to be converted in to an array? No. The reason it looks odd for "PHP" == 0 is that there's no reason why the 0 should not be converted to "0", except that strings and numbers are not the only types available and there has to be an order of precedence. And consistency is key. As for how strings get converted to numbers I have no idea why it will take everything up to the first non-e|E|. character. The documentation[1] simply states the behaviour and doesn't go in to why. However, I have to ask why it matters? Why would you want to convert '8315e839da08e2a7afe6dd12ec58245d' to an integer? If you have code that's juggling it automatically, be more explicit. It's fine to be interested in the reasons why it does what it does, but if it's causing you problems then the issue is with your code not being explicit enough, not PHP. -Stuart [1] http://php.net/language.types.string#language.types.string.conversion -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP is Zero
Just found out that MySQL uses the same implicit conversion precedence on SQL clauses. That shows me that possibly exists some "higher order" rule that states this consistency, and changing that is outside the scope of PHP. On Thu, Jun 13, 2013 at 9:20 AM, Stuart Dallas wrote: > On 13 Jun 2013, at 12:27, BUSCHKE Daniel > wrote: > > > Hi, > > > >> It gives up when it finds a non-numeric character (as the documentation > would tell you) > > > > Why is PHP doing that? I know it works as designed and I know it is > documented like this but that does not mean that it is a good feature, does > it? So lets talk about the question: Is that behaviour awaited by PHP > software developers? Is that really the way PHP should work here? May we > should change that?! > > > > BTW: I talked to some collegues and friends since my first post. They > all guessed that "'PHP' == 0" is false within a few seconds. I think the > weak-typed-PHP is a little to weak at this point. > > I don't know what the actual reasoning is; if you want that I suggest you > ask on the internals list, but be careful how you phrase the question. If > it's pure curiosity then that's fine, but whether you agree with the > reasoning or not it's gone way past the point where it can be changed. > > My take it that the behaviour is perfectly reasonable. When you compare > two different types it has to convert one of them. If you're comparing a > string to a number it seems logical to me that the number should be the > preferred type, so the string gets converted. What would you expect > array(5) == 5 to give you? Would you expect the 5 to be converted in to an > array? No. The reason it looks odd for "PHP" == 0 is that there's no reason > why the 0 should not be converted to "0", except that strings and numbers > are not the only types available and there has to be an order of > precedence. And consistency is key. > > As for how strings get converted to numbers I have no idea why it will > take everything up to the first non-e|E|. character. The documentation[1] > simply states the behaviour and doesn't go in to why. However, I have to > ask why it matters? Why would you want to convert > '8315e839da08e2a7afe6dd12ec58245d' to an integer? If you have code that's > juggling it automatically, be more explicit. It's fine to be interested in > the reasons why it does what it does, but if it's causing you problems then > the issue is with your code not being explicit enough, not PHP. > > -Stuart > > [1] http://php.net/language.types.string#language.types.string.conversion > > -- > Stuart Dallas > 3ft9 Ltd > http://3ft9.com/ > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP] Detect and Redirect Mobile Users
Hi, On Thu, Jun 13, 2013 at 1:19 AM, dealTek wrote: > Hi all, > > I'm curious of a simple, common, universal way to detect a mobile user so > I can redirect them to a mobile directory... > > What is best for this: Javascript - CSS - PHP? > > I think for my purposes if I can detect screen size or mobile browser > agent - that would be good enough for what I need right now. > > Thanks in advance - Dave > > In my personnal experiences, I've used varnish (for caching mainly) and for mobile redirection purpose. A few line in your vcl configuration and there you go. You can even put a rules to indicate that if there is a GET parameter or a cookie, you don't redirect the user. It means that you can simply add a link on your mobile website to send the user back on the desktop website if he prefers. I like this approach as it is directly on your first frontend (or load balancer) and you don't even need to load you php app to redirect the user. Regards, -- bacardi55 (bacardi55.org)
[PHP] Re: AW: AW: PHP is Zero
Il Thu, 13 Jun 2013 13:27:51 +0200, BUSCHKE Daniel ha scritto: > Why is PHP doing that? Because a decision had to be made, and they chose to do it that way. > I know it works as designed and I know it is > documented like this but that does not mean that it is a good feature, > does it? It is a political decision. In a weakly typed language (by design) you have to decide how to convert types. it is documented: http://www.php.net/manual/en/language.types.type-juggling.php http://www.php.net/manual/en/ language.types.string.php#language.types.string.conversion If you need stricter conversions, you can cast whatever you want to whatever else, and use === > So lets talk about the question: Is that behaviour awaited by > PHP software developers? Yes. At least for me. > Is that really the way PHP should work here? Yes. By design. > May we should change that?! No. It would break backwards compatibility. A lot. And it would make PHP a strongly typed language. > BTW: I talked to some collegues and friends since my first post. They > all guessed that "'PHP' == 0" is false within a few seconds. I think the > weak-typed-PHP is a little to weak at this point. Maybe because they are used to other languages. Javascript has similar rules, but Python has different ones, as it is NOT weakly typed, just dinamically typed. You just have to enter a different mindset. PHP is not Java or Python. It is PHP. You should use the way it was designed, not by any other languages rules. One of the reasons I prefer PHP over Python is because it is weakly typed (another is the spaces-tab-madness) Bye. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Enabling the chroot() function in PHP 5.4
Hi Aaron, It's better if you ask this question on the PHP internals list, there's hardly anyone compiling it's own PHP here. - Matijn On Thu, Jun 13, 2013 at 9:55 AM, Aaron Stephens wrote: > Hi All, > > Does anybody know how to enable the chroot() function in PHP 5.4? It > was easy in PHP 5.3 as long as you were building the CLI by itself. In the > PHP 5.4 configure script there is a new PHP_BINARIES variable being used > instead of setting PHP_SAPI=cli and thus the "#define ENABLE_CHROOT_FUNC 1" > is never written to the output file. I have been able to manually enable > it by adding the define to the main/php_config.h after running configure. > The issue seems to be a line: if test "program" = "program". This > comparison being true is what causes the configure script to add "cli" to > the PHP_BINARIES variable instead of setting the PHP_SAPI variable. The > other prerequisites (HAVE_CHROOT and ZTS) are all at the required settings. > It is only the ENABLE_CHROOT_FUNC which is causing the function to not be > compiled into the resulting binary. Any information or explanation would > be very helpful. > > For the record, I know what the chroot() function does and does not > do. I am experimenting with using chroot() to isolate an already running > script to a particular subset of the filesystem for file operations. > > -- > > - Aaron > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP] Detect and Redirect Mobile Users
On Thu, Jun 13, 2013 at 3:17 AM, Paul M Foster wrote: > On Wed, Jun 12, 2013 at 04:19:50PM -0700, dealTek wrote: > > > Hi all, > > > > I'm curious of a simple, common, universal way to detect a mobile user > so I can redirect them to a mobile directory... > > > > What is best for this: Javascript - CSS - PHP? > > > > I think for my purposes if I can detect screen size or mobile browser > agent - that would be good enough for what I need right now. > > This is not really a PHP question. I understand your asking it, though. > Does anyone know of a better list or whatever for generic web designer > questions? > > To your question, there are two problems: 1) Looking for a browser > signature is a needle/haystack proposition, and the haystack is > enormous, and it gets bigger every time a new phone/tablet model comes > out; 2) Screen size used to be a good indicator, but as I feared when > people first started using screen resolution as the main indicator, the > screens on mobile devices have become progressively more and more > capable. Some of them are better than many desktops I've seen. > > So I'd be interested in the answer to the question myself. > > Paul > > HI, Even though the list gets bigger, there aren't that many mobile operating systems. Any Android device will have Android in it's user agent, and iPhone as iPhone in the User Agent string. If you want to check for tablets, you can check for iPad specifically (it is in the user agent), and for Android, I believe that mobile devices have 'Mobile' in the user agent string, and tablets don't. Then there is ofcourse the small 1 percent or so Blackberry & WP users, which can probably be detected easily too with their user agent. Cheers, Matijn
Re: [PHP] Detect and Redirect Mobile Users
On Thu, Jun 13, 2013 at 3:20 PM, Matijn Woudt wrote:
>
>
>
> On Thu, Jun 13, 2013 at 3:17 AM, Paul M Foster wrote:
>
>> On Wed, Jun 12, 2013 at 04:19:50PM -0700, dealTek wrote:
>>
>> > Hi all,
>> >
>> > I'm curious of a simple, common, universal way to detect a mobile user
>> so I can redirect them to a mobile directory...
>> >
>> > What is best for this: Javascript - CSS - PHP?
>> >
>> > I think for my purposes if I can detect screen size or mobile browser
>> agent - that would be good enough for what I need right now.
>>
>> This is not really a PHP question. I understand your asking it, though.
>> Does anyone know of a better list or whatever for generic web designer
>> questions?
>>
>> To your question, there are two problems: 1) Looking for a browser
>> signature is a needle/haystack proposition, and the haystack is
>> enormous, and it gets bigger every time a new phone/tablet model comes
>> out; 2) Screen size used to be a good indicator, but as I feared when
>> people first started using screen resolution as the main indicator, the
>> screens on mobile devices have become progressively more and more
>> capable. Some of them are better than many desktops I've seen.
>>
>> So I'd be interested in the answer to the question myself.
>>
>> Paul
>>
>>
> HI,
>
> Even though the list gets bigger, there aren't that many mobile operating
> systems. Any Android device will have Android in it's user agent, and
> iPhone as iPhone in the User Agent string.
> If you want to check for tablets, you can check for iPad specifically (it
> is in the user agent), and for Android, I believe that mobile devices have
> 'Mobile' in the user agent string, and tablets don't.
>
> Then there is ofcourse the small 1 percent or so Blackberry & WP users,
> which can probably be detected easily too with their user agent.
>
> Cheers,
>
> Matijn
>
I forgot to mention, in PHP the user agent string is in
$_SERVER['HTTP_USER_AGENT'], and in javascript you can find it in
navigator.userAgent.
Where you want to redirect, it's up to you. If you want it to do on first
attempt, better go with PHP so you can use Header("Location: ...") to
redirect the user immediately so the user won't notice he is being
redirected.
Re: [PHP] Detect and Redirect Mobile Users
Hello, I stumbled upon this the other day : http://mobiledetect.net/ I haven't tried it yet, since I have my own small user agent parser when I need it, but it may help you if it's a pure php solution you're looking for. Have a nice day 2013/6/13 dealTek > Hi all, > > I'm curious of a simple, common, universal way to detect a mobile user so > I can redirect them to a mobile directory... > > What is best for this: Javascript - CSS - PHP? > > I think for my purposes if I can detect screen size or mobile browser > agent - that would be good enough for what I need right now. > > Thanks in advance - Dave > > > -- > Thanks, > Dave - DealTek > deal...@gmail.com > [db-3] > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Camille Hodoul http://camille-hodoul.com/
Re: AW: [PHP] PHP is Zero
On Thu, Jun 13, 2013 at 1:49 PM, BUSCHKE Daniel <
daniel.busc...@nextiraone.eu> wrote:
> To be more technical:
>
> If intval('8315e839da08e2a7afe6dd12ec58245d') would return NULL instead of
> 8315 then PHP would be still weak-typed and the developer could know that
> the conversion failed. Good idea? Of course NULL should be transparent in
> operations like +. So 0 + NULL should be still 0.
>
> Regards
> Daniel
>
>
It would just break too much. I see lots of scripts that have things like
this:
$var = '12 beers';
echo $var + 4;
and they expect it to be 16 of course.
Or what about badly trimmed strings, when reading from a file it can
include extra line endings and it's so much easier to just ignore that
because PHP will convert it just fine.
- Matijn
[PHP] What is the name of the pattern that will ...
Hi.
I'm building a class which needs to have certain methods called by the
subclass, but the subclass can extend but not obscure/override the
behaviour.
So, for example, a method AuthRequestMade() will record the activity of
making an authorisation request. It cannot make the actual request as that
is the subclass's job, but, no matter what, I need to have this method
called with the result of the actual auth request.
I want to make building the subclasses as simple and as fool proof as
possible.
I think I have to do something like this ...
interface AuthEnforcer{
public function AuthRequestMade(&$i_State, &$s_Message);
}
abstract class Auth implements AuthEnforcer{
public method MakeAuthRequest(){
// Do my stuff before.
// Call the SpecificAuth class
$this->AuthRequestMade($i_State, $s_Message);
// Do my stuff after with state and message.
}
}
class SpecificAuth extends Auth{
public function AuthRequestMade(&$i_State, &$s_Message){
// Do my specific stuff, setting state and message.
}
}
But a couple of things I don't like (and don't know how to avoid).
1 - The SpecificAuth::AuthRequestMade is public and I want it protected as
it shouldn't be called from the public scope.
2 - The response is by ref, but I think having a AuthResponse class
containing $i_State and $s_Message should be enough there, but no way to
enforce return types in PHP.
Any ideas?
Thank you.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
Re: [PHP] What is the name of the pattern that will ...
Hi Richard,
On Thu, Jun 13, 2013 at 10:16 AM, Richard Quadling wrote:
> I'm building a class which needs to have certain methods called by the
> subclass, but the subclass can extend but not obscure/override the
> behaviour.
>
This is the Template Method pattern, though in this case you could use a
Strategy where the specific authentication implementation is in a separate
class that gets injected into the Auth class. As for your example there a a
few things I would change.
* The template method that the subclass must implement should not be
declared by an interface. Interfaces are for declaring public contracts.
You can simply declare an abstract, protected method in Auth. This is the
contract that every subclass must fulfill.
* I would avoid reference variables as you've indicated. If you don't want
to build a data-holder class yet, simply return an array for now. While you
cannot enforce the return type at parse time, they should be verified with
unit tests. Unit tests are critical with dynamic languages like PHP and
Python since runtime is the only way to verify behavior.
Otherwise, your example is spot on, though the name AuthRequestMade implies
the request has already been made yet I think from your description that
this method should *make* the actual request. Here's how I would write it
with the above in place.
class Auth {
public function MakeAuthRequest() {
// before
$this->MakeAuthRequestImpl(); // Adding "Impl" suffix is a
common convention
// after
}
/**
* Make the actual authentication request.
*
* @return array Must contain keys "state" and "message" to hold
the result
*/
protected abstract function MakeAuthRequestImpl();
}
Peace,
David
Re: [PHP] Detect and Redirect Mobile Users
http://php.net/manual/en/misc.configuration.php#ini.browscap
http://tempdownloads.browserscap.com/
$browser = get_browser(null, TRUE);
if (isset($browser['ismobiledevice']) && ($browser['ismobiledevice'] == TRUE)) {
$isMobile = TRUE;
}
else {
$isMobile = FALSE;
}
unset($browser);
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
