Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #15716 > unrolled thread
| Started by | Derek Turner <frderek@suremail.je> |
|---|---|
| First post | 2015-10-20 18:57 +0000 |
| Last post | 2015-11-01 08:31 -0500 |
| Articles | 20 on this page of 128 — 22 participants |
Back to article view | Back to comp.lang.php
Check for military time Derek Turner <frderek@suremail.je> - 2015-10-20 18:57 +0000
Re: Check for military time Derek Turner <frderek@suremail.je> - 2015-10-20 19:00 +0000
Re: Check for military time Richard Yates <richard@yatesguitar.com> - 2015-10-20 21:35 -0700
Re: Check for military time Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-21 16:12 -0400
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-21 22:38 -0400
Re: Check for military time Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-22 10:43 -0400
Re: Check for military time Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-22 10:48 -0400
Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-22 17:20 +0200
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-22 12:19 -0400
Re: Check for military time "Peter H. Coffin" <hellsop@ninehells.com> - 2015-10-22 15:32 -0500
Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-22 23:08 +0200
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-22 20:19 -0400
Re: Check for military time Matthew Carter <m@ahungry.com> - 2015-10-22 22:07 -0400
Re: Check for military time "Beauregard T. Shagnasty" <a.nony.mous@example.invalid> - 2015-10-23 02:26 +0000
Re: Check for military time Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-22 17:13 -0400
Re: Check for military time Tim Streater <timstreater@greenbee.net> - 2015-10-22 22:57 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-22 20:22 -0400
Re: Check for military time Tim Streater <timstreater@greenbee.net> - 2015-10-23 09:19 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-23 09:32 -0400
Re: Check for military time Tim Streater <timstreater@greenbee.net> - 2015-10-23 15:43 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-23 11:11 -0400
Re: Check for military time gordonb.nwjln@burditt.org (Gordon Burditt) - 2015-10-23 12:36 -0500
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-23 13:40 -0400
Re: Check for military time Tim Streater <timstreater@greenbee.net> - 2015-10-23 18:54 +0100
Re: Check for military time Norman Peelman <npeelman@cfl.rr.com> - 2015-10-23 22:44 -0400
Re: Check for military time Tim Streater <timstreater@greenbee.net> - 2015-10-24 10:32 +0100
Re: Check for military time Derek Turner <frderek@suremail.je> - 2015-10-24 11:41 +0000
Re: Check for military time Norman Peelman <npeelman@cfl.rr.com> - 2015-10-24 15:15 -0400
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-22 20:21 -0400
Re: Check for military time Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-22 20:38 -0400
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-22 20:47 -0400
Re: Check for military time gordonb.90ylr@burditt.org (Gordon Burditt) - 2015-10-22 18:21 -0500
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-22 20:23 -0400
Re: Check for military time gordonb.c5zx1@burditt.org (Gordon Burditt) - 2015-10-22 17:40 -0500
Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-22 11:12 +0200
Re: Check for military time Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-22 11:06 -0400
Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-22 17:18 +0200
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-22 13:17 -0400
Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-21 13:55 +0200
Re: Check for military time "M. Strobel" <strobel@example.com> - 2015-10-21 20:56 +0200
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-21 16:48 -0400
Re: Check for military time Stephan Elinghaus <221015.6.seli@spamgourmet.com> - 2015-10-22 13:16 +0200
Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-22 15:11 +0200
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-22 10:23 -0400
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-10-27 14:10 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-27 09:25 -0400
Re: Check for military time Jørn Andersen <jorn@jorna.dk> - 2015-10-27 15:19 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-27 10:41 -0400
Re: Check for military time Matthew Carter <m@ahungry.com> - 2015-10-27 23:03 -0400
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-27 23:29 -0400
Re: Check for military time Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-10-29 10:08 +0100
Re: Check for military time Matthew Carter <m@ahungry.com> - 2015-10-29 21:44 -0400
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-29 22:35 -0400
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-10-30 20:08 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-30 16:22 -0400
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-01 11:58 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-01 08:27 -0500
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-01 14:36 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-01 09:05 -0500
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-01 16:51 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-01 11:09 -0500
Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-30 22:33 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-30 20:01 -0400
Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-11-03 19:51 +0100
Re: Check for military time Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-11-02 13:51 +0100
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-02 18:57 +0100
Re: Check for military time Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-11-04 15:18 +0100
Re: Check for military time Matthew Carter <m@ahungry.com> - 2015-11-04 21:18 -0500
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-05 07:51 +0100
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-10-30 20:04 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-30 16:24 -0400
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-01 12:06 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-01 08:30 -0500
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-01 14:39 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-01 09:07 -0500
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-01 16:58 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-01 11:05 -0500
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-02 08:14 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-02 10:01 -0500
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-02 17:54 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-02 12:50 -0500
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-02 19:05 +0100
Re: Check for military time Tim Streater <timstreater@greenbee.net> - 2015-11-02 18:23 +0000
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-02 15:23 -0500
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-02 15:16 -0500
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-03 05:47 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-03 08:47 -0500
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-04 03:55 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-03 22:09 -0500
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-04 08:49 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-04 08:29 -0500
Re: Check for military time Paul Herber <paul@pherber.com> - 2015-11-04 14:14 +0000
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-04 10:00 -0500
Re: Check for military time Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-11-06 13:11 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-06 09:45 -0500
Re: Check for military time Matthew Carter <m@ahungry.com> - 2015-11-07 21:50 -0500
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-07 22:05 -0500
Re: Check for military time gordonb.2zzss@burditt.org (Gordon Burditt) - 2015-11-08 20:50 -0600
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-09 10:29 +0100
Re: Check for military time gordonb.00syf@burditt.org (Gordon Burditt) - 2015-11-10 23:42 -0600
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-11 07:46 +0100
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-11 07:50 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-11 08:06 -0500
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-11 15:15 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-11 09:21 -0500
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-11 17:46 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-11 15:12 -0500
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-11 22:23 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-11 17:17 -0500
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-11 08:05 -0500
OT: Munging addresses (was: Re: Check for military time) Arno Welzel <usenet@arnowelzel.de> - 2015-11-11 19:18 +0100
Re: OT: Munging addresses Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-11 15:16 -0500
Re: OT: Munging addresses Arno Welzel <usenet@arnowelzel.de> - 2015-11-11 22:29 +0100
Re: OT: Munging addresses Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-11 17:20 -0500
Re: OT: Munging addresses Arno Welzel <usenet@arnowelzel.de> - 2015-11-12 07:47 +0100
Re: OT: Munging addresses Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-12 10:15 -0500
Re: OT: Munging addresses Arno Welzel <usenet@arnowelzel.de> - 2015-11-12 17:17 +0100
Re: OT: Munging addresses Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-12 11:59 -0500
Re: OT: Munging addresses Arno Welzel <usenet@arnowelzel.de> - 2015-11-12 18:51 +0100
Re: OT: Munging addresses Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-12 14:20 -0500
Re: OT: Munging addresses Arno Welzel <usenet@arnowelzel.de> - 2015-11-12 20:59 +0100
Re: OT: Munging addresses Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-12 16:54 -0500
Re: OT: Munging addresses Jim Higgins <ILikeMy@Privacy.invalid> - 2015-11-18 16:24 +0000
PHP code section end marker (was: Check for military time) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-10-27 22:58 +0100
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-10-30 20:01 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-30 16:27 -0400
Re: Check for military time Arno Welzel <usenet@arnowelzel.de> - 2015-11-01 12:12 +0100
Re: Check for military time Jerry Stuckle <jstucklex@attglobal.net> - 2015-11-01 08:31 -0500
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-21 16:48 -0400 |
| Message-ID | <n08tig$dvr$1@dont-email.me> |
| In reply to | #15724 |
On 10/21/2015 2:56 PM, M. Strobel wrote: > On 21.10.2015 13:55, Thomas 'PointedEars' Lahn wrote: >> Derek Turner wrote: >> >>> Is there a quick and dirty way to check that >>> >>> substr($string, 0 ,3) is a valid military time, ie. 0000-2359? >> >> Yes. >> > > "Can you tell me what time it is?" > > "Yes." > > Kindergarten. > > /Str. > What do you expect? He couldn't find someone's code to copy/paste. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Stephan Elinghaus <221015.6.seli@spamgourmet.com> |
|---|---|
| Date | 2015-10-22 13:16 +0200 |
| Message-ID | <h5tmfc-678.ln1@none.inv> |
| In reply to | #15716 |
Am 2015-10-20 hat Derek Turner geschrieben:
> Is there a quick and dirty way to check that
>
> substr($string, 0 ,3) is a valid military time, ie. 0000-2359?
Maybe this works for you:
<?php
$string="1534";
if(preg_match("/[012](((?<=2)[0123])|(?<!2)[0-9])[[0-5][0-9]/",$string))
echo "is valid";
else echo "is not valid";
?>
--
[no signature today]
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2015-10-22 15:11 +0200 |
| Message-ID | <1874827.QbCUPLQBcH@PointedEars.de> |
| In reply to | #15729 |
Stephan Elinghaus wrote:
> Am 2015-10-20 hat Derek Turner geschrieben:
>> Is there a quick and dirty way to check that
>>
>> substr($string, 0 ,3) is a valid military time, ie. 0000-2359?
>
> Maybe this works for you:
> <?php
> $string="1534";
> if(preg_match("/[012](((?<=2)[0123])|(?<!2)[0-9])[[0-5][0-9]/",$string))
Much too complicated, and still not completely safe (you have not anchored
the expression, neither on beginning or end of string or line, whitespace
nor non-digits). Consider instead:
if (preg_match('/^(?:[01]\\d|2[0-3])[0-5]\\d$/', $string))
Test code:
$ php -r 'foreach (range(-1, 24) as $h) foreach (range(-1, 60) as $m) { echo
preg_match("/^(?:[01]\\d|2[0-3])[0-5]\\d$/", sprintf("%02d", $h) .
sprintf("%02d", $m)); if ($m === 60) echo "\n"; }'
You should get a box of zeros filled only with ones (because '0' is the
string representation of “false”, and '1' of “true”). The zeros are (quite
literally) the edge cases that must not match, the ones the proper time
strings.
> echo "is valid";
> else echo "is not valid";
With all such constructs, consider instead:
echo ($boolean) ? $ifTrue : $ifFalse;
This is particularly useful if you can use “<?= … ?>” to just output the
(string representation of) the result of an expression.
> ?>
Avoid ending PHP files with that; you may be accidentally outputting
trailing whitespace otherwise.
--
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-22 10:23 -0400 |
| Message-ID | <n0ard5$937$1@dont-email.me> |
| In reply to | #15730 |
On 10/22/2015 9:11 AM, Thomas 'PointedEars' Lahn wrote:
> Stephan Elinghaus wrote:
>
>> Am 2015-10-20 hat Derek Turner geschrieben:
>>> Is there a quick and dirty way to check that
>>>
>>> substr($string, 0 ,3) is a valid military time, ie. 0000-2359?
>>
>> Maybe this works for you:
>> <?php
>> $string="1534";
>> if(preg_match("/[012](((?<=2)[0123])|(?<!2)[0-9])[[0-5][0-9]/",$string))
>
> Much too complicated, and still not completely safe (you have not anchored
> the expression, neither on beginning or end of string or line, whitespace
> nor non-digits). Consider instead:
>
> if (preg_match('/^(?:[01]\\d|2[0-3])[0-5]\\d$/', $string))
>
Much too complicated.
if (strtotime($string"))
works perfectly.
</snip>
> Avoid ending PHP files with that; you may be accidentally outputting
> trailing whitespace otherwise.
>
Another stoopid comment by the troll.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2015-10-27 14:10 +0100 |
| Message-ID | <562F77B7.1050001@arnowelzel.de> |
| In reply to | #15731 |
Jerry Stuckle schrieb am 2015-10-22 um 16:23: > On 10/22/2015 9:11 AM, Thomas 'PointedEars' Lahn wrote: [...] >> Avoid ending PHP files with that; you may be accidentally outputting >> trailing whitespace otherwise. >> > > Another stoopid comment by the troll. JFTR: PHP scripts can not only output text and additional white space at the end may invalidate the output. Omitting the closing tag does not cause any harm but will avoid this for sure. -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de http://fahrradzukunft.de
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-27 09:25 -0400 |
| Message-ID | <n0ntrp$kpq$1@dont-email.me> |
| In reply to | #15795 |
On 10/27/2015 9:10 AM, Arno Welzel wrote: > Jerry Stuckle schrieb am 2015-10-22 um 16:23: > >> On 10/22/2015 9:11 AM, Thomas 'PointedEars' Lahn wrote: > [...] >>> Avoid ending PHP files with that; you may be accidentally outputting >>> trailing whitespace otherwise. >>> >> >> Another stoopid comment by the troll. > > JFTR: PHP scripts can not only output text and additional white space at > the end may invalidate the output. Omitting the closing tag does not > cause any harm but will avoid this for sure. > > Good programming will avoid this problem, for sure. Crappy programmers need crappy workarounds. Omitting a closing tag will cause harm if someone tries to add html at the end of the page. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jørn Andersen <jorn@jorna.dk> |
|---|---|
| Date | 2015-10-27 15:19 +0100 |
| Message-ID | <ut1v2b5bkvm5378ldg5ucojj4r1k8o8vnf@4ax.com> |
| In reply to | #15796 |
On Tue, 27 Oct 2015 09:25:31 -0400, Jerry Stuckle <jstucklex@attglobal.net> wrote: >On 10/27/2015 9:10 AM, Arno Welzel wrote: <snip> >> JFTR: PHP scripts can not only output text and additional white space at >> the end may invalidate the output. Omitting the closing tag does not >> cause any harm but will avoid this for sure. >Good programming will avoid this problem, for sure. Crappy programmers >need crappy workarounds. php.net recommends not using the PHP closing tag “if a file is pure PHP code”. http://php.net/manual/en/language.basic-syntax.phptags.php >Omitting a closing tag will cause harm if someone tries to add html at >the end of the page. -- Jørn Andersen http://socialister.dk http://marxisme.dk
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-27 10:41 -0400 |
| Message-ID | <n0o2as$69i$1@dont-email.me> |
| In reply to | #15797 |
On 10/27/2015 10:19 AM, J�rn Andersen wrote: > On Tue, 27 Oct 2015 09:25:31 -0400, Jerry Stuckle > <jstucklex@attglobal.net> wrote: > >> On 10/27/2015 9:10 AM, Arno Welzel wrote: > <snip> >>> JFTR: PHP scripts can not only output text and additional white space at >>> the end may invalidate the output. Omitting the closing tag does not >>> cause any harm but will avoid this for sure. > >> Good programming will avoid this problem, for sure. Crappy programmers >> need crappy workarounds. > > php.net recommends not using the PHP closing tag “if a file is pure > PHP code”. > http://php.net/manual/en/language.basic-syntax.phptags.php > >> Omitting a closing tag will cause harm if someone tries to add html at >> the end of the page. > > First of all, that is a big "if". Second, this is an opinion of one (or a small group of) programmers which violates good coding practices which have worked for decades. But then I have never been that impressed with the programmers there. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Matthew Carter <m@ahungry.com> |
|---|---|
| Date | 2015-10-27 23:03 -0400 |
| Message-ID | <8737wvd78w.fsf@ahungry.com> |
| In reply to | #15798 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 10/27/2015 10:19 AM, J�rn Andersen wrote: >> On Tue, 27 Oct 2015 09:25:31 -0400, Jerry Stuckle >> <jstucklex@attglobal.net> wrote: >> >>> On 10/27/2015 9:10 AM, Arno Welzel wrote: >> <snip> >>>> JFTR: PHP scripts can not only output text and additional white space at >>>> the end may invalidate the output. Omitting the closing tag does not >>>> cause any harm but will avoid this for sure. >> >>> Good programming will avoid this problem, for sure. Crappy programmers >>> need crappy workarounds. >> >> php.net recommends not using the PHP closing tag “if a file is pure >> PHP code”. >> http://php.net/manual/en/language.basic-syntax.phptags.php >> >>> Omitting a closing tag will cause harm if someone tries to add html at >>> the end of the page. >> >> > > First of all, that is a big "if". Second, this is an opinion of one (or > a small group of) programmers which violates good coding practices which > have worked for decades. But then I have never been that impressed with > the programmers there. PSR recommends that definitions (classes/functions) and code producing side effects be in separate files anyways, so I see no issue with omitting a closing tag in definition files (as no HTML should be randomly added to the end anyways) and detecting that your HTML is failing to render due to being within an unclosed PHP tag is easier to debug than a closed tag with whitespace hidden afterwards. -- Matthew Carter (m@ahungry.com) http://ahungry.com
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-27 23:29 -0400 |
| Message-ID | <n0pfa8$ckm$1@dont-email.me> |
| In reply to | #15801 |
On 10/27/2015 11:03 PM, Matthew Carter wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 10/27/2015 10:19 AM, J�rn Andersen wrote: >>> On Tue, 27 Oct 2015 09:25:31 -0400, Jerry Stuckle >>> <jstucklex@attglobal.net> wrote: >>> >>>> On 10/27/2015 9:10 AM, Arno Welzel wrote: >>> <snip> >>>>> JFTR: PHP scripts can not only output text and additional white space at >>>>> the end may invalidate the output. Omitting the closing tag does not >>>>> cause any harm but will avoid this for sure. >>> >>>> Good programming will avoid this problem, for sure. Crappy programmers >>>> need crappy workarounds. >>> >>> php.net recommends not using the PHP closing tag “if a file is pure >>> PHP code”. >>> http://php.net/manual/en/language.basic-syntax.phptags.php >>> >>>> Omitting a closing tag will cause harm if someone tries to add html at >>>> the end of the page. >>> >>> >> >> First of all, that is a big "if". Second, this is an opinion of one (or >> a small group of) programmers which violates good coding practices which >> have worked for decades. But then I have never been that impressed with >> the programmers there. > > PSR recommends that definitions (classes/functions) and code producing > side effects be in separate files anyways, so I see no issue with > omitting a closing tag in definition files (as no HTML should be > randomly added to the end anyways) and detecting that your HTML is > failing to render due to being within an unclosed PHP tag is easier to > debug than a closed tag with whitespace hidden afterwards. > YOU don't see any problem. Good programmers do. Just wait until you run into a problem because of it. Your tune will change. And I'm not the only one who feels this way. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Erwin Moller <erwinmollerusenet@xs4all.nl> |
|---|---|
| Date | 2015-10-29 10:08 +0100 |
| Message-ID | <5631e20e$0$23743$e4fe514c@news.xs4all.nl> |
| In reply to | #15802 |
On 10/28/2015 4:29 AM, Jerry Stuckle wrote: > On 10/27/2015 11:03 PM, Matthew Carter wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 10/27/2015 10:19 AM, J�rn Andersen wrote: >>>> On Tue, 27 Oct 2015 09:25:31 -0400, Jerry Stuckle >>>> <jstucklex@attglobal.net> wrote: >>>> >>>>> On 10/27/2015 9:10 AM, Arno Welzel wrote: >>>> <snip> >>>>>> JFTR: PHP scripts can not only output text and additional white space at >>>>>> the end may invalidate the output. Omitting the closing tag does not >>>>>> cause any harm but will avoid this for sure. >>>> >>>>> Good programming will avoid this problem, for sure. Crappy programmers >>>>> need crappy workarounds. >>>> >>>> php.net recommends not using the PHP closing tag “if a file is pure >>>> PHP code”. >>>> http://php.net/manual/en/language.basic-syntax.phptags.php >>>> >>>>> Omitting a closing tag will cause harm if someone tries to add html at >>>>> the end of the page. >>>> >>>> >>> >>> First of all, that is a big "if". Second, this is an opinion of one (or >>> a small group of) programmers which violates good coding practices which >>> have worked for decades. But then I have never been that impressed with >>> the programmers there. >> >> PSR recommends that definitions (classes/functions) and code producing >> side effects be in separate files anyways, so I see no issue with >> omitting a closing tag in definition files (as no HTML should be >> randomly added to the end anyways) and detecting that your HTML is >> failing to render due to being within an unclosed PHP tag is easier to >> debug than a closed tag with whitespace hidden afterwards. >> > > YOU don't see any problem. Good programmers do. > > Just wait until you run into a problem because of it. Your tune will > change. And I'm not the only one who feels this way. > Seconded. Always use the closing tag. <opinionated> If you get into trouble because you produce output after the closing tag, get another job. If that is over your head, you should change jobs, not the programming language (or usage of it). It isn't that hard. This advice from php.net is ridiculous. This reminds me a lot of the curly bracket in conditional statements. Some seem to think omitting them is alright for single statements. It is, of course, not alright to omit them. </opinionated> Regards, Erwin Moller -- "That which can be asserted without evidence, can be dismissed without evidence." -- Christopher Hitchens
[toc] | [prev] | [next] | [standalone]
| From | Matthew Carter <m@ahungry.com> |
|---|---|
| Date | 2015-10-29 21:44 -0400 |
| Message-ID | <87y4elb05f.fsf@ahungry.com> |
| In reply to | #15803 |
Erwin Moller <erwinmollerusenet@xs4all.nl> writes:
> On 10/28/2015 4:29 AM, Jerry Stuckle wrote:
>>
>> YOU don't see any problem. Good programmers do.
>>
>> Just wait until you run into a problem because of it. Your tune will
>> change. And I'm not the only one who feels this way.
>>
>
> Seconded.
> Always use the closing tag.
>
> <opinionated>
> If you get into trouble because you produce output after the closing
> tag, get another job.
> If that is over your head, you should change jobs, not the programming
> language (or usage of it).
> It isn't that hard.
> This advice from php.net is ridiculous.
>
> This reminds me a lot of the curly bracket in conditional statements.
> Some seem to think omitting them is alright for single statements.
> It is, of course, not alright to omit them.
> </opinionated>
>
> Regards,
> Erwin Moller
Other than a feeling of self righteousness, what is gained again?
Tell me, in these two sample files, which is easier to debug if the
aforementioned use cases occurred that cause an error when the file is
included by another file making use of header responses:
------------------File One (no closing tag, misplaced HTML)-----------
<?php
function add($a, $b) {
return $a + $b;
}
<h1>This is my great page of addition!</h1>
------------------File Two (closing tag, extra space)-----------------
<?php
function add($a, $b) {
return $a + $b;
}
?>
Assuming both were included/required in another file, which one would
the majority of programmers have an easier time pinpointing the error
with? (hint: the one where the PHP error reporting would tell you
exactly where the faulty HTML was originating, NOT the file that was
outputting some whitespace before a header call - that error would send
you to the header() call line, not the bad file with trailing space).
There have been 0 good reasons for including a closing tag (it's just too
bad we can't actually have a '.phpdef' file type or something that
simulates a 100% PHP only file, without dropping in and out of tags and
just avoids the use of the <?php ?> nonsense entirely).
--
Matthew Carter (m@ahungry.com)
http://ahungry.com
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-29 22:35 -0400 |
| Message-ID | <n0ukt5$tbe$1@dont-email.me> |
| In reply to | #15805 |
On 10/29/2015 9:44 PM, Matthew Carter wrote:
> Erwin Moller <erwinmollerusenet@xs4all.nl> writes:
>
>> On 10/28/2015 4:29 AM, Jerry Stuckle wrote:
>>>
>>> YOU don't see any problem. Good programmers do.
>>>
>>> Just wait until you run into a problem because of it. Your tune will
>>> change. And I'm not the only one who feels this way.
>>>
>>
>> Seconded.
>> Always use the closing tag.
>>
>> <opinionated>
>> If you get into trouble because you produce output after the closing
>> tag, get another job.
>> If that is over your head, you should change jobs, not the programming
>> language (or usage of it).
>> It isn't that hard.
>> This advice from php.net is ridiculous.
>>
>> This reminds me a lot of the curly bracket in conditional statements.
>> Some seem to think omitting them is alright for single statements.
>> It is, of course, not alright to omit them.
>> </opinionated>
>>
>> Regards,
>> Erwin Moller
>
> Other than a feeling of self righteousness, what is gained again?
>
> Tell me, in these two sample files, which is easier to debug if the
> aforementioned use cases occurred that cause an error when the file is
> included by another file making use of header responses:
>
> ------------------File One (no closing tag, misplaced HTML)-----------
> <?php
>
> function add($a, $b) {
> return $a + $b;
> }
>
> <h1>This is my great page of addition!</h1>
>
> ------------------File Two (closing tag, extra space)-----------------
> <?php
>
> function add($a, $b) {
> return $a + $b;
> }
>
> ?>
>
>
> Assuming both were included/required in another file, which one would
> the majority of programmers have an easier time pinpointing the error
> with? (hint: the one where the PHP error reporting would tell you
> exactly where the faulty HTML was originating, NOT the file that was
> outputting some whitespace before a header call - that error would send
> you to the header() call line, not the bad file with trailing space).
>
> There have been 0 good reasons for including a closing tag (it's just too
> bad we can't actually have a '.phpdef' file type or something that
> simulates a 100% PHP only file, without dropping in and out of tags and
> just avoids the use of the <?php ?> nonsense entirely).
>
Proper coding techniques and it wouldn't happen in the first place.
But to answer your question - the problem is your test can cause a fatal
error, potentially displaying internal information to a user. This
information could be used to hack the system.
But I know you will dismiss any reason given, so go ahead and make a
fool of yourself. You've obviously never worked on a multi-programmer
project with coding conventions.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2015-10-30 20:08 +0100 |
| Message-ID | <5633C02A.60502@arnowelzel.de> |
| In reply to | #15807 |
Jerry Stuckle schrieb am 2015-10-30 um 03:35:
> On 10/29/2015 9:44 PM, Matthew Carter wrote:
>> Erwin Moller <erwinmollerusenet@xs4all.nl> writes:
>>
>>> On 10/28/2015 4:29 AM, Jerry Stuckle wrote:
>>>>
>>>> YOU don't see any problem. Good programmers do.
>>>>
>>>> Just wait until you run into a problem because of it. Your tune will
>>>> change. And I'm not the only one who feels this way.
>>>>
>>>
>>> Seconded.
>>> Always use the closing tag.
>>>
>>> <opinionated>
>>> If you get into trouble because you produce output after the closing
>>> tag, get another job.
>>> If that is over your head, you should change jobs, not the programming
>>> language (or usage of it).
>>> It isn't that hard.
>>> This advice from php.net is ridiculous.
>>>
>>> This reminds me a lot of the curly bracket in conditional statements.
>>> Some seem to think omitting them is alright for single statements.
>>> It is, of course, not alright to omit them.
>>> </opinionated>
>>>
>>> Regards,
>>> Erwin Moller
>>
>> Other than a feeling of self righteousness, what is gained again?
>>
>> Tell me, in these two sample files, which is easier to debug if the
>> aforementioned use cases occurred that cause an error when the file is
>> included by another file making use of header responses:
>>
>> ------------------File One (no closing tag, misplaced HTML)-----------
>> <?php
>>
>> function add($a, $b) {
>> return $a + $b;
>> }
>>
>> <h1>This is my great page of addition!</h1>
>>
>> ------------------File Two (closing tag, extra space)-----------------
>> <?php
>>
>> function add($a, $b) {
>> return $a + $b;
>> }
>>
>> ?>
>>
>>
>> Assuming both were included/required in another file, which one would
>> the majority of programmers have an easier time pinpointing the error
>> with? (hint: the one where the PHP error reporting would tell you
>> exactly where the faulty HTML was originating, NOT the file that was
>> outputting some whitespace before a header call - that error would send
>> you to the header() call line, not the bad file with trailing space).
>>
>> There have been 0 good reasons for including a closing tag (it's just too
>> bad we can't actually have a '.phpdef' file type or something that
>> simulates a 100% PHP only file, without dropping in and out of tags and
>> just avoids the use of the <?php ?> nonsense entirely).
>>
>
> Proper coding techniques and it wouldn't happen in the first place.
>
> But to answer your question - the problem is your test can cause a fatal
> error, potentially displaying internal information to a user. This
> information could be used to hack the system.
Therefore one
1) will TEST stuff BEFORE it goes to the production system
2) configures the production system in a way that it will NEVER display
ANY error to the user
Do you really want to tell us you don't know that?
> But I know you will dismiss any reason given, so go ahead and make a
> fool of yourself. You've obviously never worked on a multi-programmer
> project with coding conventions.
And you seem to never have worked on real production systems. And yes -
omitting closing tags *can* be a coding convention within the team as well.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-30 16:22 -0400 |
| Message-ID | <n10jcj$qei$1@dont-email.me> |
| In reply to | #15814 |
On 10/30/2015 3:08 PM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-10-30 um 03:35:
>> On 10/29/2015 9:44 PM, Matthew Carter wrote:
>>> Erwin Moller <erwinmollerusenet@xs4all.nl> writes:
>>>
>>>> On 10/28/2015 4:29 AM, Jerry Stuckle wrote:
>>>>>
>>>>> YOU don't see any problem. Good programmers do.
>>>>>
>>>>> Just wait until you run into a problem because of it. Your tune will
>>>>> change. And I'm not the only one who feels this way.
>>>>>
>>>>
>>>> Seconded.
>>>> Always use the closing tag.
>>>>
>>>> <opinionated>
>>>> If you get into trouble because you produce output after the closing
>>>> tag, get another job.
>>>> If that is over your head, you should change jobs, not the programming
>>>> language (or usage of it).
>>>> It isn't that hard.
>>>> This advice from php.net is ridiculous.
>>>>
>>>> This reminds me a lot of the curly bracket in conditional statements.
>>>> Some seem to think omitting them is alright for single statements.
>>>> It is, of course, not alright to omit them.
>>>> </opinionated>
>>>>
>>>> Regards,
>>>> Erwin Moller
>>>
>>> Other than a feeling of self righteousness, what is gained again?
>>>
>>> Tell me, in these two sample files, which is easier to debug if the
>>> aforementioned use cases occurred that cause an error when the file is
>>> included by another file making use of header responses:
>>>
>>> ------------------File One (no closing tag, misplaced HTML)-----------
>>> <?php
>>>
>>> function add($a, $b) {
>>> return $a + $b;
>>> }
>>>
>>> <h1>This is my great page of addition!</h1>
>>>
>>> ------------------File Two (closing tag, extra space)-----------------
>>> <?php
>>>
>>> function add($a, $b) {
>>> return $a + $b;
>>> }
>>>
>>> ?>
>>>
>>>
>>> Assuming both were included/required in another file, which one would
>>> the majority of programmers have an easier time pinpointing the error
>>> with? (hint: the one where the PHP error reporting would tell you
>>> exactly where the faulty HTML was originating, NOT the file that was
>>> outputting some whitespace before a header call - that error would send
>>> you to the header() call line, not the bad file with trailing space).
>>>
>>> There have been 0 good reasons for including a closing tag (it's just too
>>> bad we can't actually have a '.phpdef' file type or something that
>>> simulates a 100% PHP only file, without dropping in and out of tags and
>>> just avoids the use of the <?php ?> nonsense entirely).
>>>
>>
>> Proper coding techniques and it wouldn't happen in the first place.
>>
>> But to answer your question - the problem is your test can cause a fatal
>> error, potentially displaying internal information to a user. This
>> information could be used to hack the system.
>
> Therefore one
>
> 1) will TEST stuff BEFORE it goes to the production system
>
> 2) configures the production system in a way that it will NEVER display
> ANY error to the user
>
> Do you really want to tell us you don't know that?
>
Trolls like you need their hands held.
>> But I know you will dismiss any reason given, so go ahead and make a
>> fool of yourself. You've obviously never worked on a multi-programmer
>> project with coding conventions.
>
> And you seem to never have worked on real production systems. And yes -
> omitting closing tags *can* be a coding convention within the team as well.
>
>
You have no idea. I've worked on MUCH larger production systems than
you could ever think of. How about one with over 10,000 concurrent
users, for instance?
And yes, committing closing tags can be a coding convention - for trolls
and newbies. Good programmers close their tags.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2015-11-01 11:58 +0100 |
| Message-ID | <5635F049.3020000@arnowelzel.de> |
| In reply to | #15815 |
Jerry Stuckle schrieb am 2015-10-30 um 21:22: > On 10/30/2015 3:08 PM, Arno Welzel wrote: >> Jerry Stuckle schrieb am 2015-10-30 um 03:35: [...] >>> But I know you will dismiss any reason given, so go ahead and make a >>> fool of yourself. You've obviously never worked on a multi-programmer >>> project with coding conventions. >> >> And you seem to never have worked on real production systems. And yes - >> omitting closing tags *can* be a coding convention within the team as well. > > You have no idea. I've worked on MUCH larger production systems than > you could ever think of. How about one with over 10,000 concurrent > users, for instance? You want to play the "my dick is bigger" game? Really? This is your argument? You loose. -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de http://fahrradzukunft.de
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-11-01 08:27 -0500 |
| Message-ID | <n153rh$6kb$1@dont-email.me> |
| In reply to | #15820 |
On 11/1/2015 5:58 AM, Arno Welzel wrote: > Jerry Stuckle schrieb am 2015-10-30 um 21:22: > >> On 10/30/2015 3:08 PM, Arno Welzel wrote: >>> Jerry Stuckle schrieb am 2015-10-30 um 03:35: > [...] >>>> But I know you will dismiss any reason given, so go ahead and make a >>>> fool of yourself. You've obviously never worked on a multi-programmer >>>> project with coding conventions. >>> >>> And you seem to never have worked on real production systems. And yes - >>> omitting closing tags *can* be a coding convention within the team as well. >> >> You have no idea. I've worked on MUCH larger production systems than >> you could ever think of. How about one with over 10,000 concurrent >> users, for instance? > > You want to play the "my dick is bigger" game? Really? This is your > argument? You loose. > > You're the one who brought up the "real production systems", not me. I don't argue with trolls. I'm just pointing out what a loser you are. But then all trolls are losers. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2015-11-01 14:36 +0100 |
| Message-ID | <56361577.8080409@arnowelzel.de> |
| In reply to | #15823 |
Jerry Stuckle schrieb am 2015-11-01 um 14:27: > On 11/1/2015 5:58 AM, Arno Welzel wrote: >> Jerry Stuckle schrieb am 2015-10-30 um 21:22: >> >>> On 10/30/2015 3:08 PM, Arno Welzel wrote: >>>> Jerry Stuckle schrieb am 2015-10-30 um 03:35: >> [...] >>>>> But I know you will dismiss any reason given, so go ahead and make a >>>>> fool of yourself. You've obviously never worked on a multi-programmer >>>>> project with coding conventions. >>>> >>>> And you seem to never have worked on real production systems. And yes - >>>> omitting closing tags *can* be a coding convention within the team as well. >>> >>> You have no idea. I've worked on MUCH larger production systems than >>> you could ever think of. How about one with over 10,000 concurrent >>> users, for instance? >> >> You want to play the "my dick is bigger" game? Really? This is your >> argument? You loose. >> >> > > You're the one who brought up the "real production systems", not me. I > don't argue with trolls. I'm just pointing out what a loser you are. And it was you bringing up this: "But to answer your question - the problem is your test can cause a fatal error, potentially displaying internal information to a user. This information could be used to hack the system." And this is something which will NEVER happen in a production system. A production system MUST NOT display errors to a user. You can not be sure that errors will NEVER happen - even when you end all your scripts with closing tags. Many things can go wrong during runtime - e.h. database connections may not be available etc.. And for all these cases you MUST ensure that users will NEVER see error messages with internal details about the production system. And yes, this is possible, even for PHP. So even bringing up the possibility that a *user* of a system may see error messages with internal information shows me that you either don't have experience in how to configure and run production systems or you assume that everybody here is just a hobbyist and does not understand the difference between a development system and production system. -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de http://fahrradzukunft.de
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-11-01 09:05 -0500 |
| Message-ID | <n1562e$g0a$1@dont-email.me> |
| In reply to | #15826 |
On 11/1/2015 8:36 AM, Arno Welzel wrote: > Jerry Stuckle schrieb am 2015-11-01 um 14:27: > >> On 11/1/2015 5:58 AM, Arno Welzel wrote: >>> Jerry Stuckle schrieb am 2015-10-30 um 21:22: >>> >>>> On 10/30/2015 3:08 PM, Arno Welzel wrote: >>>>> Jerry Stuckle schrieb am 2015-10-30 um 03:35: >>> [...] >>>>>> But I know you will dismiss any reason given, so go ahead and make a >>>>>> fool of yourself. You've obviously never worked on a multi-programmer >>>>>> project with coding conventions. >>>>> >>>>> And you seem to never have worked on real production systems. And yes - >>>>> omitting closing tags *can* be a coding convention within the team as well. >>>> >>>> You have no idea. I've worked on MUCH larger production systems than >>>> you could ever think of. How about one with over 10,000 concurrent >>>> users, for instance? >>> >>> You want to play the "my dick is bigger" game? Really? This is your >>> argument? You loose. >>> >>> >> >> You're the one who brought up the "real production systems", not me. I >> don't argue with trolls. I'm just pointing out what a loser you are. > > And it was you bringing up this: > > "But to answer your question - the problem is your test can cause a > fatal error, potentially displaying internal information to a user. > This information could be used to hack the system." > > And this is something which will NEVER happen in a production system. A > production system MUST NOT display errors to a user. > That's true. And using closing tags is one more step which can prevent it. > You can not be sure that errors will NEVER happen - even when you end > all your scripts with closing tags. Many things can go wrong during > runtime - e.h. database connections may not be available etc.. And for > all these cases you MUST ensure that users will NEVER see error messages > with internal details about the production system. And yes, this is > possible, even for PHP. > No, you cannot be sure errors will never happen. You also cannot be sure that your php.ini file will never be changed. It is NEVER possible to have 100% assurance that error messages will never be displayed. But using closing tags is one more level of protection against it happening. > So even bringing up the possibility that a *user* of a system may see > error messages with internal information shows me that you either don't > have experience in how to configure and run production systems or you > assume that everybody here is just a hobbyist and does not understand > the difference between a development system and production system. > > The fact you don't consider it possible proves you don't have the necessary experience to work on a production system. You don't even rate hobbyist level. You're nothing more than a troll. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2015-11-01 16:51 +0100 |
| Message-ID | <563634EF.7080601@arnowelzel.de> |
| In reply to | #15828 |
Jerry Stuckle schrieb am 2015-11-01 um 15:05: > On 11/1/2015 8:36 AM, Arno Welzel wrote: >> Jerry Stuckle schrieb am 2015-11-01 um 14:27: [...] >> And it was you bringing up this: >> >> "But to answer your question - the problem is your test can cause a >> fatal error, potentially displaying internal information to a user. >> This information could be used to hack the system." >> >> And this is something which will NEVER happen in a production system. A >> production system MUST NOT display errors to a user. >> > > That's true. And using closing tags is one more step which can prevent it. You don't get my point: a production system MUST NOT display errors to a user - regardless what caused the error. >> You can not be sure that errors will NEVER happen - even when you end >> all your scripts with closing tags. Many things can go wrong during >> runtime - e.h. database connections may not be available etc.. And for >> all these cases you MUST ensure that users will NEVER see error messages >> with internal details about the production system. And yes, this is >> possible, even for PHP. >> > > No, you cannot be sure errors will never happen. You also cannot be > sure that your php.ini file will never be changed. It is NEVER possible > to have 100% assurance that error messages will never be displayed. But > using closing tags is one more level of protection against it happening. Wrong - mission critical configuration settings MUST stay as defined. Otherwise the responsible persons should better look for another job. >> So even bringing up the possibility that a *user* of a system may see >> error messages with internal information shows me that you either don't >> have experience in how to configure and run production systems or you >> assume that everybody here is just a hobbyist and does not understand >> the difference between a development system and production system. >> >> > > The fact you don't consider it possible proves you don't have the > necessary experience to work on a production system. You don't even > rate hobbyist level. You're nothing more than a troll. I don't know what you consider "professional" - but I wouldn't consider stupid things like allowing internal error messages to be disaplayed to the user on a production system just because one of the developers created a formal error in one of his scripts and putting them to the production system without testing it. I would also never let a software developer touch the php.ini of a production system without doing a review or even let anyone put scripts to production without testing at all. -- Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de http://fahrradzukunft.de
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.php
csiph-web