Hi,
This little patch makes the following changes to the CLI web server's
console logging:
- Compacts messages to one line, so a 404 doesn't occupy three lines.
- Includes the response status code
- Colours messages according to their response code (success=green,
client error=yellow, server error=red) - Appends the error message when there's a fatal PHP error
Here's an example:
http://spellign.com/patches/cli-before.png
http://spellign.com/patches/cli-after.png
And the patch:
http://spellign.com/patches/php-trunk-cli-server-messages.patch
I'd appreciate any feedback.
Regards,
Arpad
Hi,
This little patch makes the following changes to the CLI web server's
console logging:
- Compacts messages to one line, so a 404 doesn't occupy three lines.
- Includes the response status code
- Colours messages according to their response code (success=green,
client error=yellow, server error=red)- Appends the error message when there's a fatal PHP error
Here's an example:
http://spellign.com/patches/cli-before.png
http://spellign.com/patches/cli-after.pngAnd the patch:
http://spellign.com/patches/php-trunk-cli-server-messages.patchI'd appreciate any feedback.
Regards,
Arpad
--
I would love to have this. :)
Tyrael
- Colours messages according to their response code (success=green,
client error=yellow, server error=red)
I would prefer if this would be an ini option (if (cli_web_server.color
&& isatty) color = true) default can be on, but I've seen cases where
such magic failed and created hard-to use results (due to control
sequences in log files or such).
johannes
2011/6/29 Johannes Schlüter johannes@schlueters.de:
- Colours messages according to their response code (success=green,
client error=yellow, server error=red)I would prefer if this would be an ini option (if (cli_web_server.color
&& isatty) color = true) default can be on, but I've seen cases where
such magic failed and created hard-to use results (due to control
sequences in log files or such).
I agree with johannes. Color should be an option, all term does not
handle them correctly. Also, color control sequences are just killing
a log file.
++ Jerome
2011/6/29 Johannes Schlüter johannes@schlueters.de:
- Colours messages according to their response code (success=green,
client error=yellow, server error=red)I would prefer if this would be an ini option (if (cli_web_server.color
&& isatty) color = true) default can be on, but I've seen cases where
such magic failed and created hard-to use results (due to control
sequences in log files or such).I agree with johannes. Color should be an option, all term does not
handle them correctly. Also, color control sequences are just killing
a log file.
That's why the patch first checks whether stdout is actually a tty, so
your log file will not have ansi control characters.
Derick
That's why the patch first checks whether stdout is actually a tty, so
your log file will not have ansi control characters.
While that check is not always the best/good thing. For instance if
you're using script(1) to log a terminal session you will end up with a
log file with control sequences.
Script started on June 29, 2011 12:59:59 PM CEST
$ cat test.c
#include <unistd.h>
int main() {
printf("%i\n", isatty(STDOUT_FILENO));
return 0;
}
$ gcc -otest test.c
$ ./test
1
$ exit
script done on June 29, 2011 01:02:11 PM CEST
And then there are people using "strange" backgrounds or have trouble
identifying specific colors - so I think it should be made optional.
johannes
- Colours messages according to their response code (success=green,
client error=yellow, server error=red)I would prefer if this would be an ini option (if (cli_web_server.color
&& isatty) color = true) default can be on, but I've seen cases where
such magic failed and created hard-to use results (due to control
sequences in log files or such).johannes
I'm -1 on the color coding for a few reasons: (i) it can be done
outside of PHP (ii) forcing a particular color coding is problematic
for many users (iii) the escape codes are not portable.
The other items in the patch have merit.
If you're looking at the web server code, perhaps you can sort out the
issues with subdirectories and include()? Moriyoshi has gone quiet
on it.
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
- Colours messages according to their response code (success=green,
client error=yellow, server error=red)I would prefer if this would be an ini option (if (cli_web_server.color
&& isatty) color = true) default can be on, but I've seen cases where
such magic failed and created hard-to use results (due to control
sequences in log files or such).
The code could detect if it's outputting to a TTY or not and only use color codes if the output isn't redirected somewhere else.
David
- Colours messages according to their response code (success=green,
client error=yellow, server error=red)I would prefer if this would be an ini option (if (cli_web_server.color
&& isatty) color = true) default can be on, but I've seen cases where
such magic failed and created hard-to use results (due to control
sequences in log files or such).The code could detect if it's outputting to a TTY or not and only use
color codes if the output isn't redirected somewhere else.
It is checking this. And I showed an example (script(1)) where the
environment pretends to be a TTY and isn't. My suggestion was to add an
ini option in addition to the check.
johannes
- Colours messages according to their response code (success=green,
client error=yellow, server error=red)I would prefer if this would be an ini option (if (cli_web_server.color
&& isatty) color = true) default can be on, but I've seen cases where
such magic failed and created hard-to use results (due to control
sequences in log files or such).The code could detect if it's outputting to a TTY or not and only use
color codes if the output isn't redirected somewhere else.It is checking this. And I showed an example (script(1)) where the
environment pretends to be a TTY and isn't. My suggestion was to add an
ini option in addition to the check.
I'm fine with that, but let's leave it set to 1 by default? People with
complex requirements can then turn it off if they want to.
regards,
Derick
- Colours messages according to their response code (success=green,
client error=yellow, server error=red)I would prefer if this would be an ini option (if (cli_web_server.color
&& isatty) color = true) default can be on, but I've seen cases where
such magic failed and created hard-to use results (due to control
sequences in log files or such).The code could detect if it's outputting to a TTY or not and only use
color codes if the output isn't redirected somewhere else.It is checking this. And I showed an example (script(1)) where the
environment pretends to be a TTY and isn't. My suggestion was to add an
ini option in addition to the check.I'm fine with that, but let's leave it set to 1 by default? People with
complex requirements can then turn it off if they want to.regards,
Derick--
In Windows, there is no default colouring support at the console, so
it would make sense if it was off by default.
I use a tool called ANSICon which provides the colouring support
(http://en.wikipedia.org/wiki/ANSI_escape_code#Support and source+bins
at http://adoxa.110mb.com/ansicon/).
So, for me turning it on would work for me.
Richard.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
agreed, it should be optional and off by default. PHP never had such
feature either.
2011/6/30 Johannes Schlüter johannes@schlueters.de:
- Colours messages according to their response code (success=green,
client error=yellow, server error=red)I would prefer if this would be an ini option (if (cli_web_server.color
&& isatty) color = true) default can be on, but I've seen cases where
such magic failed and created hard-to use results (due to control
sequences in log files or such).The code could detect if it's outputting to a TTY or not and only use
color codes if the output isn't redirected somewhere else.It is checking this. And I showed an example (script(1)) where the
environment pretends to be a TTY and isn't. My suggestion was to add an
ini option in addition to the check.johannes
--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
Good idea :)
However I would prefer to have that enabled optionally. CLI is widely
used for automated tasks with logs created using std* redirects. I
would not like to have the color escape codes in these logs.
Also please open a FR at bugs.php.net and attach the patch(es) to it, thanks!
Cheers,
Hi,
This little patch makes the following changes to the CLI web server's
console logging:
- Compacts messages to one line, so a 404 doesn't occupy three lines.
- Includes the response status code
- Colours messages according to their response code (success=green,
client error=yellow, server error=red)- Appends the error message when there's a fatal PHP error
Here's an example:
http://spellign.com/patches/cli-before.png
http://spellign.com/patches/cli-after.pngAnd the patch:
http://spellign.com/patches/php-trunk-cli-server-messages.patchI'd appreciate any feedback.
Regards,
Arpad
--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org