[php] binnen een loop een file lezen die verandert

[marty]

om de commandline te simuleren heb ik een scriptje geschreven wat hier uit bestaat:

file met 2 iframes
1. geeft de output van de commands weer
2. kun je de commands geven

op het moment dat je een command geeft post het bestand naar zichzelf en voegt een regel toe aan commands.txt

het is idee was: het bestand in het iframe (1.) die de output moet echoën heeft een oneindige loop en bekijkt telkens of de filegrootte verandert

dit is het loopje:

PHP:

$file = "commands.txt";
$loep = True;
while($loep)
{
    if (!isset($filesize))
    {
        if (file_exists($file))
            $filesize = filesize($file);
        else
            $filesize = 0;
        $loep = exec_command($file);
        echo "not set - ".$filesize." -<br>\n";
        flush();
    }
    else
    {
        if (file_exists($file))
        {
            $cur_filesize = filesize($file);
            if ($cur_filesize > $filesize)
            {
                $filesize = $cur_filesize;
                $loep = exec_command($file);
                echo "difference<br>\n";
                flush();
            }
/*          else
            {
                echo "no difference<br>\n";
                flush();
            }
*/      }
    }
}

die functie die ik aanroep leest het laatste commando uit en print die naar het scherm. of beëindigd het geheel bij het juiste commando door dan False terug te geven (en wist de inhoud van die file).

Leuk bedacht....maar het werk niet.
Als ik een commando geef blijft ie gewoon laden, alsof de file niet verandert - en pas als ik 'm onderbreek door dat iframe te refreshen ziet ie het nieuwe commando staan.
Op 1 of andere manier, als ie de filegrootte eenmaal heeft bepaalt, wil ie er binnen dat script (loopje) niet meer aan dat dat misschien verandert.
Iemand een idee wat het is en hoe dit op te lossen? Ik zat zelf te denken aan een soort caching probleem, maar kon er niets over vinden

[Grijze Vos]

je wilt met een javascriptje op een submit die eerste IFrame verversen. PHP doet zn werk, en stopt dan, totdat je hem opnieuw aanroept. Je kunt niet een script laten blijven executen. Een script termineert sowieso binnen 30 seconden oid.

[marty]

javascript???? nee hoor, lees m'n begin post nog maar eens goed.

Een script termineert sowieso binnen 30 seconden oid.

dat kun je aanpassen dooe de max. execution time op oneindig te zetten.

maargoed, dit zijn helemaal geen problemen. M'n probleem is het uitlezen van die filegrootte, die wel verandert, maar dat heeft php dus op 1 of andere vage reden niet in de gaten

[Grijze Vos]

Je wil absoluut niet de max. exec. time op oneindig zetten. Dat is manier #1 om je bak hard te laten crashen.

Stel je voor, een script, in oneindige loop, wat iets op een mysql database doet, en daardoor 10% load slurpt. Toevallig zitten daar een paar man naar te kijken, bam, 100% serverload, dag dag server.. Kun je hopen dat je bak dual proc is en de tweede processor nog wat tijd overheeft om dat eerste proces af te schieten...

[marty]

Grijze Vos schreef op 10 October 2003 @ 22:49:
Je wil absoluut niet de max. exec. time op oneindig zetten.

ja dat wil ik wel.

Dat is manier #1 om je bak hard te laten crashen.

ik weet gerust wel waar ik mee bezig ben en dan nog, het is gewoon een thuisservertje, dus het maakt geen moer uit wat er mee gebeurt

Stel je voor, een script, in oneindige loop, wat iets op een mysql database doet, en daardoor 10% load slurpt.

Kijk even naar m'n code/uitleg die hierboven staat en je zult zien dat er niets spannends gebeurt.

Nu weer ontopic graag.

[Verwijderd]

Grijze Vos schreef op 10 October 2003 @ 22:37:
je wilt met een javascriptje op een submit die eerste IFrame verversen. PHP doet zn werk, en stopt dan, totdat je hem opnieuw aanroept. Je kunt niet een script laten blijven executen. Een script termineert sowieso binnen 30 seconden oid.

Het antwoord wordt al gegeven. Je kunt gewoon met javascript gewoon de frame verversen wanneer het nodig is. Het is over het algemeen geen goed id om een script constant te laten draaien.

Conclusie: gebruik gewoon javascript

[jimjimmus]

Ok, blijkbaar wordt de filegrootte niet echt telkens weer opgevraagd. Er zijn een aantal oplossingen voor je probleem:

1. Je hebt geen server-side loop nodig: Je kunt de feedback van de commands terug laten komen in het 2e frame en dat frame het 1e frame laten updaten m.b.v. javascript. Stel je krijgt $feedback terug van je exec_command, dan stop je die niet in een file, maar je echoot in je 2e frame:
echo "<script>showFeedback($feedback)</script>"

met
function showFeedback($str) {
// in IE4+, in Moz gaat het vergelijkbaar, maar dan met DOM
parent.frame1.document.body.insertAdjacentHTML("beforeEnd", $str+"<br>");
}

2. Je kunt ook gebruik maken van persistent sockets, die constant data naar het bovenste frame flushen. Zie php.net hiervoor. Flash kan nog beter met socket-verbindingen omgaan, maar ik weet niet of je je op dat pad wilt begeven.

Succes.

[Verwijderd]

je kunt ook een metatag in de pagina plaatsen die om de x seconden refreshed...

[Grijze Vos]

Het gaat niet zo zeer om dit script marty, maar in het algemeen. Als er andere code straks draait, en die crashed, kun je je bak telkens rebooten. Tja, tis je eigen keuze hoor, mij zul je nooit dat soort settings zo extreem zien veranderen..

[Verwijderd]

Iedereen die hier praat over de max execution time is natuurlijk ervan op de hoogte dat je dat gewoon per bestand/functie/conditie aan kunt passen (www.php.net/function.set-time-limit)

Persoonlijk zou ik denk ik aan een socket verbinding denken bij een dergelijke vraag.

[marty]

Verwijderd schreef op 11 oktober 2003 @ 03:14:
Iedereen die hier praat over de max execution time is natuurlijk ervan op de hoogte dat je dat gewoon per bestand/functie/conditie aan kunt passen

Ja uiteraard; ik ga dat natuurlijk niet in m'n ini zelf uitzetten.....

Aan iedereen die met refresh oplossingen is gekomen: Dat gaat niet. M'n script mag niet eindigen namelijk. Sommige commando's zul je namelijk in meerdere stappen moeten doen. Daarom doe ik al die moeite dat script draaiende te houden.

Persoonlijk zou ik denk ik aan een socket verbinding denken bij een dergelijke vraag.

je vermoed dus dat als ik fsockopen() gebruik ipv fopen dat ik dan het probleem met die filesize niet heb?
Ik zal het morgen eens gaan proberen. nu eerst naar bedzzzzzz

[bigtree]

Punt 1: je kan wel de executie op oneindig zetten, maar als een browser (lees: IE) meer dan 5 minuten geen feed krijgt, stopt hij met downloaden. Ik heb wel eens zitten proberen deze tijd aan te passen, maar dat bleek onbegonnen werk. En daarvoor moet een aanpassing in het register worden gemaakt... ellende dus. Je ontkomt gewoon niet aan een refresh.

Punt 2: het is niet noodzakelijk je script tot in oneindigheid door te laten lopen als bepaalde dingen in meerdere stappen worden uitgevoerd. Daar heb je sessies voor.

[slm]

Misschien komt het omdat de filesize() result wordt gecached.

PHP manual zegt:
"Invoking the stat or lstat system call on most systems is quite expensive. Therefore, the result of the last call to any of the status functions (listed below) is stored for use on the next such call using the same filename. If you wish to force a new status check, for instance if the file is being checked many times and may change or disappear, use this function to clear the results of the last call from memory.

This value is only cached for the lifetime of a single request."

Je zou dan evt clearstatcache() kunnen proberen zoals in de manual staat.

[marty]

bigtree schreef op 11 October 2003 @ 10:56:
Punt 1: je kan wel de executie op oneindig zetten, maar als een browser (lees: IE)

Zijn er nog mensen die IE gebruiken dan? Mozilla is toch de standaard tegenwoordig

Punt 2: het is niet noodzakelijk je script tot in oneindigheid door te laten lopen als bepaalde dingen in meerdere stappen worden uitgevoerd. Daar heb je sessies voor.

Dat snap ik niet helemaal. Stel dat ik als commando geef
cd ..
ls
en m'n script stopt en ik start 'm weer overnieuw (met sessies?) hoe kom ik volgens jou dan weer in die dir eronder terecht? Door alle commando's eerder al in de sessie op te slaan, daar uit te trekken en opnieuw uit te voeren? Dat lijkt me nogal gevaarlijk als je bestanden gaat verwijderen enzo.

slm schreef op 11 October 2003 @ 11:56:
Misschien komt het omdat de filesize() result wordt gecached.
[...]
Je zou dan evt clearstatcache() kunnen proberen zoals in de manual staat.

Daar was ik net achtergekomen en dat werkt inderdaad. Zit nu nog met een ander probleempje, maar dat ga ik eerst zelf wel proberen op te lossen (en vandaag toch geen tijd meer voor trouwens)

[bigtree]

marty schreef op 11 October 2003 @ 12:41:
[...]

Dat snap ik niet helemaal. Stel dat ik als commando geef
cd ..
ls
en m'n script stopt en ik start 'm weer overnieuw (met sessies?) hoe kom ik volgens jou dan weer in die dir eronder terecht? Door alle commando's eerder al in de sessie op te slaan, daar uit te trekken en opnieuw uit te voeren? Dat lijkt me nogal gevaarlijk als je bestanden gaat verwijderen enzo.

Ow ja, dat doet natuurlijk niet wat je wilt. Maarrehhh... over gevaarlijk gesproken... je wilt een shell via het web mogelijk maken? Is SSH ineens niet goed genoeg meer?

[marty]

Nee, ben gewoon op m'n thuisservertje aan het klooien
Ik werd getriggerd door iemand die in een ander forum vroeg of dmv zoiets het mogelijk was te telnetten. Dus het is puur kijken of zoiets mogelijk is. Het hoeft dus niet practisch te zijn in de zin van een beter alternatief voor SSH afzo, daar ben ik niet naar opzoek.

[bigtree]

Dan loop je al snel tegen de beperkingen van een stateless protocol als http aan. ;-) Alle beveiligingsrisico's daargelaten. Kortom; ik zou er niet aan beginnen.

[marty]

bigtree schreef op 13 October 2003 @ 11:04:
Dan loop je al snel tegen de beperkingen van een stateless protocol als http aan. ;-) Alle beveiligingsrisico's daargelaten. Kortom; ik zou er niet aan beginnen.

dat is juist de reden dat ik er wél aan begonnen ben

[Verwijderd]

Dit is al de XXX-ste keer dat ik iemand een php script zie posten die 'realtime' om input wacht. PHP met HTTP is hiervoor NIET geschikt !!!

Een php script (als webpagina) moet (zo snel mogelijk) eindigen !!!

De while loop moet je simuleren door de pagina telkens te verversen via javascript...

En de output van het laatste commando zou je gewoon clientside kunnen onthouden d.m.v. javascript: window.resultframe.document.write("Commandoutput");

Op deze manier hoef je serverside niets meer te onthouden en alleen maar het actuele commando uit te voeren en het result daarvan om te zetten in document.write...

[ Voor 41% gewijzigd door Verwijderd op 13-10-2003 16:33 ]

[marty]

Verwijderd schreef op 13 October 2003 @ 16:25:
Dit is al de XXX-ste keer dat ik iemand een php script zie posten die 'realtime' om input wacht. PHP met HTTP is hiervoor NIET geschikt !!!

nou en? dat weet ik zelf ook wel. maar ik mag het toch een uitdaging vinden te kijken in hoeverre ik dit toch voor elkaar krijg? wat een gezeur op niets af zeg.

De while loop moet je simuleren door de pagina telkens te verversen via javascript...

En de output van het laatste commando zou je gewoon clientside kunnen onthouden d.m.v. javascript: window.resultframe.document.write("Commandoutput");

Op deze manier hoef je serverside niets meer te onthouden en alleen maar het actuele commando uit te voeren en het result daarvan om te zetten in document.write...

Zoals ik inmiddels al in twee eerdere posts heb geschreven heeft dat geen nut. Op het moment dat het php script beëindigd wordt moet je weer van voren af aan beginnen. Kun je wel leuk de output op het scherm bewaren, maar als ik een cd commando geef en de output bewaart dan de directorie waar ik heen gegaan ben en het script zit vervolgens weer in de oorspronkelijke dir dan schiet je daar dus weinig mee op.

[Verwijderd]

Marty: Het was verder niet negatief bedoeld... Het valt me alleen op dat veel mensen dit proberen...

Maar ik moet je echt teleurstellen, hier is een webserver scripting taal echt niet voor geschikt!! De browser wacht echt niet oneindig lang op de uitvoer van het PHP script, je krijgt een keer een timeout....

Meer mensen op deze pagina hebben al geroepen dat je met sessies of iets dergelijks moet werken... Geloof me, dat is ECHT de beste oplossing...

Je kun in de sessie heel eenvoudig bijhouden wat de current directory is en of de persoon is ingelogd... Je kunt zijn laatste statements onthouden etc..
Mocht de sessie verlopen, dan moet de persoon opnieuw inlogggen... Zet de sessie-timeout redelijk hoog en dan is dat ook absoluut geen probleem...

Ik vind het niet echt handig dat je de hulp van anderen gezeur noemt.... Waarom vraag je het dan als je zoveel beter weet?

Laat event weten of het is gelukt...

[ Voor 3% gewijzigd door Verwijderd op 14-10-2003 09:10 ]

[Verwijderd]

offtopic:
Hij heeft een experimentje bedacht en daarbij loopt ie tegen een klein probleempje aan wat daar in principe los van staat. In plaats van te helpen met z'n probleempje loopt iedereen te mekkeren dat zijn experiementje geen zin heeft omdat http er niet geschikt voor is. NOU EN. Dat wil niet zeggen dat het niet mogelijk is.... Het stimuleert je geest om de beperkingen van het leven te overwinnen (dus). Naar mijn mening terecht dat ie het gezeur noemt.

PHP:

$filesize = `ls -la $logfile | awk '{print $5}'`;

[ Voor 3% gewijzigd door Verwijderd op 14-10-2003 10:51 ]

[Verwijderd]

Het is niet onmogelijk, alleen onpraktisch en niet echt handig...
Het is echt geen gezeur als mensen hem op beter geschikte alternatieven wijzen..

Maar ok, het is een prima uitdaging en het is niet onmoglijk... Misschien zelfs de ideale oefening om de beperkingen van de HTTP/PHP omgeving te verkennen...

MARTY: IK ben nog steeds benieuwd of het je gaat lukken en tegen welke beperkingen je aanloopt (zoals de browser timeout) etc...

[bigtree]

Ok, here's the deal... een shell is persistent, een php-script (in principe) niet. De truc is dan om twee php-scripts te laten draaien: eentje die de shell in leven houdt en output flusht (naar een tekstbestand, maar liever naar een database in verband met concurrency) en eentje die de nieuwste output naar de client stuurt. Dit laatste scriptje hoeft maar heel even te draaien, de andere draait tot de shell eindigt.
Ik geef toe; het is te doen, maar dit WIL je simpelweg niet. Je bouwt namelijk een virtuele shell en wat als daar iets mis mee gaat? Geheugenlekken waar je niet goed van wordt. (Beveiligingsrisico's anyone?) Kortom; niet doen!