php-general Digest 20 May 2012 20:30:08 -0000 Issue 7818

[php-general-digest-help]

php-general Digest 20 May 2012 20:30:08 - Issue 7818

Topics (messages 317908 through 317912):

Re: errors not showing
317908 by: Simon J Welsh
317909 by: Tim Dunphy
317910 by: tamouse mailing lists
317912 by: Maciek Sokolewicz

Re: regexp novice
317911 by: Geoff Shang

Administrivia:

To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net

To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net

To post to the list, e-mail:
php-gene...@lists.php.net


--
---BeginMessage---
On 20/05/2012, at 3:55 PM, Tim Dunphy wrote:

 hello, list!
 
 I have 'error_reporting = E_ALL' set in my php.ini file. However when
 I run a php script that has errors in it all that happens is that the
 page WSODs. I am running Mac OS X 10.6. Any thoughts on why errors
 don't show up in the browser and how to correct this?
 
 
 Thanks
 Tim

You also need to set display_errors to On.
---
Simon Welsh
Admin of http://simon.geek.nz/

---End Message---
---BeginMessage---
Hello Simon,

 Thanks for your response.

 However I still can't seem to get errors to show up.

[dunphy@localhost:~/jf-current] #cat /private/etc/php.ini | grep -e
error_reporting -e display_errors
; display_errors
; error_reporting
error_reporting = E_ALL  E_NOTICE
;error_reporting = E_ALL  ~E_DEPRECATED
display_errors = On
; separately from display_errors. PHP's default behavior is to suppress those
; Eval the expression with current error_reporting().  Set to true if you want
; error_reporting(0) around the eval().

[dunphy@localhost:~/jf-current] #sudo apachectl -t
Syntax OK

[dunphy@localhost:~/jf-current] #sudo apachectl restart


[dunphy@localhost:~/jf-current] #uname -a
Darwin localhost 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7
16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 i386

I was wondering if there might be something else I might've missed?

Thanks
Tim

On Sat, May 19, 2012 at 11:57 PM, Simon J Welsh si...@welsh.co.nz wrote:
 On 20/05/2012, at 3:55 PM, Tim Dunphy wrote:

 hello, list!

 I have 'error_reporting = E_ALL' set in my php.ini file. However when
 I run a php script that has errors in it all that happens is that the
 page WSODs. I am running Mac OS X 10.6. Any thoughts on why errors
 don't show up in the browser and how to correct this?


 Thanks
 Tim

 You also need to set display_errors to On.
 ---
 Simon Welsh
 Admin of http://simon.geek.nz/




-- 
GPG me!!

gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
---End Message---
---BeginMessage---
On Sat, May 19, 2012 at 11:16 PM, Tim Dunphy bluethu...@gmail.com wrote:
 Hello Simon,

  Thanks for your response.

  However I still can't seem to get errors to show up.

 [dunphy@localhost:~/jf-current] #cat /private/etc/php.ini | grep -e
 error_reporting -e display_errors
 ; display_errors
 ; error_reporting
 error_reporting = E_ALL  E_NOTICE
 ;error_reporting = E_ALL  ~E_DEPRECATED
 display_errors = On
 ; separately from display_errors. PHP's default behavior is to suppress those
 ; Eval the expression with current error_reporting().  Set to true if you want
 ; error_reporting(0) around the eval().

 [dunphy@localhost:~/jf-current] #sudo apachectl -t
 Syntax OK

 [dunphy@localhost:~/jf-current] #sudo apachectl restart


 [dunphy@localhost:~/jf-current] #uname -a
 Darwin localhost 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7
 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 i386

 I was wondering if there might be something else I might've missed?

 Thanks
 Tim

 On Sat, May 19, 2012 at 11:57 PM, Simon J Welsh si...@welsh.co.nz wrote:
 On 20/05/2012, at 3:55 PM, Tim Dunphy wrote:

 hello, list!

 I have 'error_reporting = E_ALL' set in my php.ini file. However when
 I run a php script that has errors in it all that happens is that the
 page WSODs. I am running Mac OS X 10.6. Any thoughts on why errors
 don't show up in the browser and how to correct this?


 Thanks
 Tim

 You also need to set display_errors to On.
 ---
 Simon Welsh
 Admin of http://simon.geek.nz/




 --
 GPG me!!

 gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B

 --
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php


Are these syntax errors or run-time errors? The former won't display
to the page at all, as they abort PHP before that point. Those written
to wherever PHP is set to log errors, which might be the same as the
apache error log unless you've set something specifically for it in
php.ini.

The best way I've found to suss out syntax errors is to lint the
source file with php -l from the command line.

On the other hand, if they are not syntax errors, then make sure you
set error_reporting and display_errors (I also always set
display_startup_errors as well) soon enough to catch them (and that
nothing you include turns them off).
---End 

Re: [PHP] regexp novice

[Geoff Shang]

Stuart Dallas stu...@3ft9.com wrote:


On 18 May 2012, at 14:50, Jim Giner wrote:


Daft is a little harsh.  :)  00:40 is just not a time value that is
generally accepted.



It may appear harsh, but as far as I'm concerned it is daft to make
assumptions like that. You've essentially disallowed 12:nn am, but allowed
1:nn am, 2:nn am, 3:nn am, etc, because you're not validating the data in a
non-ambiguous way. I have no idea what you're developing, but you're making
a big assumption about the data that you're getting, which may appear
reasonable to you, but to me it's daft. Nothing personal, just my opinion,
which is all I have to offer.


Unless I've missed something, he hasn't disallowed 12:nn am, only 00:nn. 
If you're going to only accept 12-hour input, this is the right thing to 
do.  00:nn is not a valid 12-hour representation - only times from 1:nn to 
12:nn are acceptable.  If you were to accept 00:nn, you'd have to also 
accept 13:nn-23:nn as well, for consistancy.


Granted, not specifying am or pm adds a layer of ambiguity, but maybe 
that's not relevant for this query.  For example, maybe there's also a 
select field that has am and pm as options.


As it appears that accepting only 12-hour input is part of the brief, Jim 
is IMHO doing the right thing.


Geoff.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] errors not showing

[Maciek Sokolewicz]

On 20-05-2012 07:17, tamouse mailing lists wrote:

Are these syntax errors or run-time errors? The former won't display
to the page at all, as they abort PHP before that point. Those written
to wherever PHP is set to log errors, which might be the same as the
apache error log unless you've set something specifically for it in
php.ini.

The best way I've found to suss out syntax errors is to lint the
source file with php -l from the command line.

On the other hand, if they are not syntax errors, then make sure you
set error_reporting and display_errors (I also always set
display_startup_errors as well) soon enough to catch them (and that
nothing you include turns them off).


I always find it useful to check these values not by grep'ing the 
php.ini file, but by checking phpinfo() output. Just make a new file with

?php
phpinfo();

in it, and run it in the browser. That will show you the values of 
display_errors and error_reporting that are actually used. I have seen 
cases where the php.ini file a person thought was being used was 
actually NOT used, and as such changing values inside that file had no 
effect.


- Tul

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] errors not showing

[tamouse mailing lists]

On Sun, May 20, 2012 at 3:30 PM, Maciek Sokolewicz
maciek.sokolew...@gmail.com wrote:
 On 20-05-2012 07:17, tamouse mailing lists wrote:

 Are these syntax errors or run-time errors? The former won't display
 to the page at all, as they abort PHP before that point. Those written
 to wherever PHP is set to log errors, which might be the same as the
 apache error log unless you've set something specifically for it in
 php.ini.

 The best way I've found to suss out syntax errors is to lint the
 source file with php -l from the command line.

 On the other hand, if they are not syntax errors, then make sure you
 set error_reporting and display_errors (I also always set
 display_startup_errors as well) soon enough to catch them (and that
 nothing you include turns them off).


 I always find it useful to check these values not by grep'ing the php.ini
 file, but by checking phpinfo() output. Just make a new file with
 ?php
 phpinfo();

 in it, and run it in the browser. That will show you the values of
 display_errors and error_reporting that are actually used. I have seen cases
 where the php.ini file a person thought was being used was actually NOT
 used, and as such changing values inside that file had no effect.

 - Tul

Good point! Seems best to see what the application believes is
happening. The phpinfo() will also tell you just which php.ini file(s)
is(are) being read. Usual caveats about leaving such a file
unprotected on a publicly accessible server and what not.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php