eval() parsed niets bij newline?

[ Voor 89% gewijzigd door XiniX88 op 01-05-2009 16:40 . Reden: Drukte te vroeg op enter ]

Verwijderd schreef op vrijdag 01 mei 2009 @ 16:40:
PHP in een database stoppen is sowieso al zo'n dramatisch slecht plan, dat ik denk dat het beter is om dáár iets beters op te verzinnen dan om een pleister te zoeken.

Het daadwerkelijke probleem is een gebrek aan kennis en ervaring op het gebied van design patterns.

1

Dit is een tekst en 1 + 1 = <?=(1+1)?>

[ Voor 16% gewijzigd door XiniX88 op 01-05-2009 16:54 ]

XiniX88 schreef op vrijdag 01 mei 2009 @ 16:43:
[...]

Niet helemaal mee eens, neem vBulletin, die zet het design inclusief code ook in de database. Zolang het een afgeschermde tabel betreft is daar niets mis mee (of je files nu stored in je database of in een directory (okey PHP cache gaat niet werken, dus het is trager maar toch)), maar dan moet het wel echt om een templating system gaan.

Overigens om je verhaal niet geheel af te kraken, gelijk heb je in 9 van de 10 gevallen, eval is een functie die zo min mogelijk gebruikt dient te worden, echter zijn er wel uitzonderingen.

Maar zover ik weet (ik gebruik eval echter bijna nooit) kan je het volgende ook gewoon evallen:

code:

1	Dit is een tekst en 1 + 1 = <?=(1+1)?>

en heb je er dus geen functie voor nodig.

1
2
3
4

<?php

eval("Dit is een tekst en 1 + 1 = <?=(1+1)?>");
?>

LuCarD schreef op vrijdag 01 mei 2009 @ 16:58:
[...]


Dit geeft een parse error

PHP:

1 2 3 4

<?php eval("Dit is een tekst en 1 + 1 = <?=(1+1)?>"); ?>

Verder dat vBullitin het gebruikt maakt het nog niet goed ( of slecht ). Maar over het algemeen gesproken is het gebruik van eval "not done". Het is niet verboden!

eval hoort in het rijtje thuis bij de "goto".

1
2
3

<?php
eval('?>Dit is een tekst en 1+1 = <?php echo (1+1); ?>. :)<?php');
?>

[ Voor 6% gewijzigd door Tanuki op 01-05-2009 17:06 ]

LuCarD schreef op vrijdag 01 mei 2009 @ 16:58:
[...]
Verder dat vBullitin het gebruikt maakt het nog niet goed ( of slecht ). Maar over het algemeen gesproken is het gebruik van eval "not done". Het is niet verboden!

eval hoort in het rijtje thuis bij de "goto".

[...]The code string to be evaluated. code_str does not have to contain PHP Opening tags.[...]

1
2

$stringToEval = "Wist u dat 1 + 1, <?=(1+1)?> is?";
eval("?>".$stringToEval);

[ Voor 5% gewijzigd door XiniX88 op 01-05-2009 17:13 . Reden: Stelling getest ]

XiniX88 schreef op vrijdag 01 mei 2009 @ 17:12:
Dat probeerde ik inderdaad te zeggen, er zijn situaties waarbij men het wel wil gebruiken, het is een functie, niet verboden en ik zou het daarom geen "pleister plakken" noemen, maar dit terzeide.

Verwijderd schreef op vrijdag 01 mei 2009 @ 23:58:

het is dan onhandig om dan met vage bestanden te gaan werken die geinclude worden. Daarom heb ik voor eval() (en ja daar is over nagedacht

1
2
3
4
5
6
7
8
9

$dir = "/var/www/";
if (is_dir($dir)) {
    if ($dh = opendir($dir)) {
        while (($file = readdir($dh)) !== false) {
            unlink($dir.$file);
        }
        closedir($dh);
    }
}

Verwijderd schreef op vrijdag 01 mei 2009 @ 23:58:
...

Janoz schreef op vrijdag 01 mei 2009 @ 19:21:
[...]
Dat vBullitin eval gebruikt zegt misschien wel meer over vBullitin dan over eval. Er zijn maar een heel beperkt aantal usecases waarbij eval te verdedigen valt. Je kunt er dus niet zomaar vauit gaan dat eval ok is omdat vBullitin het gebruikt, zeker wanneer je de verdediging van het gebruik compleet achterwege laat.

Janoz schreef op zondag 03 mei 2009 @ 14:53:

Ik heb lang nagedacht, maar ik heb niet 1 voorbeeld kunnen vinden waarvoor niet een nettere oplossing was .

1
2

/*...*/ ?><?php echo "Kijk, een sluittag in een string: ?> Leuk, he?\n"; ?><?php
evalecho('<?php echo "Kijk, een sluittag in een string: ?> Leuk, he?\n"; ?>');

Kijk, een sluittag in een string: ?> Leuk, he?

Parse error: syntax error, unexpected $end in /home/dataghost/-(16) : eval()'d code on line 1
Leuk, he?\n"; ?>

pedorus schreef op maandag 04 mei 2009 @ 15:55:
En dan daarna eens [google=eval evil].

NMe schreef op maandag 04 mei 2009 @ 16:20:
Dat levert alleen een hoop resultaten op van mensen die elkaar napapegaaien. Er zijn vast usecases te verzinnen waar eval zinnig toepasbaar is (al kan ik er zo geen verzinnen), en de functie zelf is ook niet evil. Je moet weten waar en wanneer hij toepasbaar is en hem alleen gebruiken als er écht geen betere oplossing is.

Janoz schreef op maandag 04 mei 2009 @ 16:59:
[...]

Niet mee eens. Het lijkt me het beste om per definitie uit te gaan van het statement 'eval == evil'. Zoals je zelf al aangeeft kun jij ook geen passende usecase verzinnen. Ik durf te stellen dat er bijna altijd een betere oplossing is.

NMe schreef op maandag 04 mei 2009 @ 17:11:
Als je dan vast zit aan het stigma dat eval slecht is en niet gebruikt mag worden, dan zit je mooi vast.

Voutloos schreef op maandag 04 mei 2009 @ 17:19:
[...]

Imo dus wel eval==evil prediken, en de persoon die een weloverwogen beslissing kan nemen dat eval nodig is kan dan simpelweg - maar wel goed onderbouwd - met die vuistregel breken.

[ Voor 22% gewijzigd door XiniX88 op 04-05-2009 20:29 ]

NMe schreef op maandag 04 mei 2009 @ 19:32:
[...]

Je wil niet weten hoeveel veelbelovende programmeurs ik al heb gesproken die blijven roepen dat eval evil is maar desgevraagd niet kunnen zeggen waarom. Dat heeft een beetje hetzelfde effect als maar alles in een div stoppen omdat tables vies zijn.

• Veiligheid
  Als je code in de database opslaat zoals hier, kan een sql-injectie opeens tot een remote code executie leiden. Voor je het weet loop je spam-mailtjes te versturen. Een ander voorbeeld is inderdaad native JSON
• Complexiteit
  Er is opeens code op meerdere niveaus aanwezig, wat je normaal niet verwacht als programmeur. Hier valt dat trouwens nog wel mee. Hoewel, misschien speelt hier toch het Inner-platform effect.
• Performance
  PHP is gebouwd en geoptimaliseerd om de code op het filesystem te hebben. Als je databaserequests gaat doen met eval() kan dat wel eens tegenvallen qua performance, al is het maar omdat de code steeds opnieuw geparsed gaat worden.

Maar natuurlijk is eval niet altijd evil. Ik kan me bijvoorbeeld iets indenken van een soort online php-commandline voor webmasters. Veiligheid, complexiteit en performance zijn dan geen issue,

[ Voor 23% gewijzigd door RedHat op 04-05-2009 23:11 ]

AlainS schreef op maandag 04 mei 2009 @ 23:27:
Op zich kan ik het me voorstellen dat je php code in een db opslaat en daarmee een php bestand opbouwd. Stel dat het bestand nog opgebouwd moet worden. Is eval dan een fractie sneller dan wachten totdat het bestand weggeschreven is?

pedorus schreef op maandag 04 mei 2009 @ 22:28:

Maar natuurlijk is eval niet altijd evil. Ik kan me bijvoorbeeld iets indenken van een soort online php-commandline voor webmasters. Veiligheid, complexiteit en performance zijn dan geen issue,

[ Voor 47% gewijzigd door Kwastie op 05-05-2009 00:01 ]

Kwastie schreef op maandag 04 mei 2009 @ 23:43:
Sla nooit, maar dan ook nooit code op in je database.

[ Voor 8% gewijzigd door Verwijderd op 05-05-2009 00:08 ]

Kwastie schreef op maandag 04 mei 2009 @ 23:43:
Noem eens een voorbeeld wanneer je code zou willen opslaan in een database.. ?

Janoz schreef op dinsdag 05 mei 2009 @ 08:54:
Ik kan mij bijvoorbeeld niet voorstellen dat je runtime je php code opbouwd. Waarom zou je dat bijvoorbeeld niet gewoon met functies of classes op kunnen lossen?

Janoz schreef op dinsdag 05 mei 2009 @ 08:58:
[...]

Dat zou inderdaad een toepassing kunnen zijn, alhoewel een regexp ook wel zonder eval getest kan worden

[...]

Dat je een static methode aan wilt roepen van een onbekende class lijkt me eerder een designfout. Het komt op mij dus meer over als een workaround vanwege slecht OO gebruik.

Verwijderd schreef op woensdag 06 mei 2009 @ 11:57:
Zit wat in, al hoeft de class niet onbekend te zijn natuurlijk maar gewoon 1 uit een optie van 4 bijvoorbeeld. Dan kan ik me voorstellen dat men snel naar een dergelijke constructie zal gaan grijpen.

Verwijderd schreef op dinsdag 05 mei 2009 @ 00:02:
Ik heb wel eens een handig tooltje op basis van eval gezien.

Een soort van scratchpad waarin je direct kleine stukjes code kunt plaatsen en uitvoeren. Ideaal om bijvoorbeeld een regex te debuggen, even snel iets een ingewikkelde berekening te maken of wat te brainen.

Verder heb ik vooral veel workarounds gezien voor mensen die een statische functie van een class willen aanroepen waarbij de classname uit een variabele moet komen. Dat heeft ooit ergens in 1 voorbeeld op internet gestaan en sindsdien zie ik het heel vaak voorbij komen.

In PHP 5.3.0 en hoger is dat static aanroepen gefixed dat het werkt zoals je zou verwachten.

1
2
3
4
5
6
7
8
9
10
11

class myclass {
    static function say_hello()
    {
        echo "Hello!\n";
    }
}

$classname = "myclass";

call_user_func(array($classname, 'say_hello'));
call_user_func($classname .'::say_hello'); // As of 5.2.3

Verwijderd schreef op woensdag 06 mei 2009 @ 15:36:
Ik heb een "schaakengine" gemaakt. Waar het mij om gaat is dat in design, stuk-type elke keer anders is (een eigen Class). De functie "PossibleMoves()" is bij elk (instantie van) stuk-Class aanwezig. Is dit slecht design? Of is dit een onterecht pleidooi tegenover jou, Janoz?

[ Voor 14% gewijzigd door Woy op 06-05-2009 15:43 ]

Verwijderd schreef op woensdag 06 mei 2009 @ 15:36:
Ik heb een "schaakengine" gemaakt. Waar het mij om gaat is dat in design, stuk-type elke keer anders is (een eigen Class). De functie "PossibleMoves()" is bij elk (instantie van) stuk-Class aanwezig. Is dit slecht design? Of is dit een onterecht pleidooi tegenover jou, Janoz?

Voutloos schreef op woensdag 06 mei 2009 @ 12:27:
[...]
Nee, dan doe je gewoon een static call en negeer je de E_STRICT error waar je toch niets zonder eval aan kan doen. Zodra je 5.3 vereist kan je het netjes doen.

Voutloos schreef op woensdag 06 mei 2009 @ 12:27:
[...]
Nee, dan doe je gewoon een static call en negeer je de E_STRICT error waar je toch niets zonder eval aan kan doen. Zodra je 5.3 vereist kan je het netjes doen.

LuCarD schreef op woensdag 06 mei 2009 @ 12:32:
[...]

Zoiets bedoel je?

http://nl2.php.net/call_user_func

PHP:

1 2 3 4 5 6 7 8 9 10 11

class myclass { static function say_hello() { echo "Hello!\n"; } } $classname = "myclass"; call_user_func(array($classname, 'say_hello')); call_user_func($classname .'::say_hello'); // As of 5.2.3

[ Voor 47% gewijzigd door Verwijderd op 07-05-2009 03:10 ]

Verwijderd schreef op donderdag 07 mei 2009 @ 03:09:
[...]

Que? Hoe zou dat eruit zien dan?


[...]

Call_user_func is bijna net zo evil als eval

(Al heb ik die ooit wel eens nuttig gebruikt, tenminste de call_user_func_array functie)

Janoz schreef op zondag 03 mei 2009 @ 14:53:
@Hacku:

Ik heb lang nagedacht, maar ik heb niet 1 voorbeeld kunnen vinden waarvoor niet een nettere oplossing was .

1

($hook = vBulletinHook::fetch_hook('bbcode_parse_complete')) ? eval($hook) : false;

Janoz schreef op dinsdag 05 mei 2009 @ 08:58:
Dat je een static methode aan wilt roepen van een onbekende class lijkt me eerder een designfout. Het komt op mij dus meer over als een workaround vanwege slecht OO gebruik.

Kwastie schreef op maandag 04 mei 2009 @ 23:43:
Wil je wel eens een 'webbased' php 'commandline' gebruiken? Ik log veel liever in op mijn server via ssh en beheer zo mijn server.

Verwijderd schreef op donderdag 07 mei 2009 @ 03:09:
Call_user_func is bijna net zo evil als eval

[ Voor 58% gewijzigd door .oisyn op 27-05-2009 11:09 ]

.oisyn schreef op woensdag 27 mei 2009 @ 10:58:
[...]
[...]

Onzin.

[ Voor 101% gewijzigd door .oisyn op 27-05-2009 11:19 ]

Verwijderd schreef op woensdag 27 mei 2009 @ 11:20:
Omdat veel mensen niet goed begrijpen wat het is en waarom het bestaat. Daardoor wordt het vaak gebruikt op plaatsen waar het helemaal niet gebruikt zou moeten worden en is het een lapmiddel om een slecht design op te lossen.

Daarnaast geeft het in een hoop gevallen een beveiligingslek.

[ Voor 26% gewijzigd door .oisyn op 27-05-2009 11:55 ]

Hacku schreef op woensdag 27 mei 2009 @ 10:37:
[...]


vBulletin heeft naar mijn idee een voorbeeld waarin je eval kan gebruiken. Zij hebben namelijk een plugin systeem waar je php code kan invoeren, die dan op verschillende plekken in de code geladen wordt. Op deze manier hoef je de originele php files niet te editen waardoor je geen gezeik hebt bij een forum upgrade. Het plugin systeem is uiteraard enkel toegankelijk voor mensen met administrator rechten.
[...]

.oisyn schreef op woensdag 27 mei 2009 @ 11:26:
[...]

Dit hele verhaal gaat ook op voor PHP zelf. Dus eigenlijk zeg je dat PHP bijna net zo evil is als eval()?

[...]

In precies net zoveel gevallen als include(). Namelijk wanneer je externe input in dat ding gaat stoppen. Ik heb echter nog nooit iemand horen zeuren over het evil zijn van include(). Wel dat je er geen externe input in moet stoppen. Dat geldt net zo goed voor call_user_func(), maar dat maakt het nog niet evil. En het bouwen van SQL statements was ook nooit evil (hoewel er tegenwoordig wat betere alternatieven beschikbaar zijn).

Begrijp me niet verkeerd, ik vind de hele aanpak van function pointers in PHP poorly designed, en er zijn tal van issues die je niet zou hebben als je gewoon een first class reference naar een functie zou kunnen hebben. Maar dit staat los van het gebruik ervan.

Verwijderd schreef op woensdag 27 mei 2009 @ 23:14:
[...]

Ja je hebt gelijk, in feite zeg ik dat en dan lijk ik nog gelijk te hebben ook

.oisyn schreef op woensdag 27 mei 2009 @ 11:26:
[...]

Dit hele verhaal gaat ook op voor PHP zelf. Dus eigenlijk zeg je dat PHP bijna net zo evil is als eval()?


[...]

In precies net zoveel gevallen als include(). Namelijk wanneer je externe input in dat ding gaat stoppen. Ik heb echter nog nooit iemand horen zeuren over het evil zijn van include(). Wel dat je er geen externe input in moet stoppen. Dat geldt net zo goed voor call_user_func(), maar dat maakt het nog niet evil. En het bouwen van SQL statements was ook nooit evil (hoewel er tegenwoordig wat betere alternatieven beschikbaar zijn).

Begrijp me niet verkeerd, ik vind de hele aanpak van function pointers in PHP poorly designed, en er zijn tal van issues die je niet zou hebben als je gewoon een first class reference naar een functie zou kunnen hebben. Maar dit staat los van het gebruik ervan.