PHP Parameter für Shell Umgebung
Gerold
- php
Hallo,
ich suche nach Eingabeparameter fuer PHP-Programme in
Shell-Umgebung. Folgendes soll funktioneren:
Die ersten vier Bedienungen erfüllen sich bei einen einfachen PHP-Prog.
fast von allein. Bei der letzten Bedienung habe ich Schwierigkeiten.
Unten habe ich ein Beispielprogramm (zum Ausprobieren den Text in Datei
kopieren, mit chmod das x-Flag setzen und starten). Das Beispielprogramm
soll zeigen, dass jedes Byte ausserhalb der Script-Tags <? ... ?> stoert
(nicht den PHP interpreter sondern in der Ausgabe des Programms).
Nimmt man den "ich bin boeser Text!" Text heraus (einschliesslich
Leerzeichen und Retruns!!!) läuft das Programm einwandfrei - sind
ausserhalb der Script-Tags irgendweche Zeichen eingebaut, stoeren
sie in der Standartausgabe.
Das Beispielprogramm selbst (wandelt ein Binärfile in Hexdaten oder
umgekehr um) intressiert mich dabei wenig!!! Mir geht es nur darum,
wie ich den PHP-Interpreter anweisen kann, alle oben genannten
Bedienungen gleichzeitig zu erfüllen.
Das ich bereits eine Menge mit den PHP Parametern rumgespielt habe,
versteht sich von selbst.
Danke für Antwort, Gerold
[Dateianfang]
#!/usr/bin/php
<?php
// Programm zum ein-, aus- und verhexen
switch ($argv[1])
{
case '-e':
while (! feof(STDIN))
{
fwrite(STDOUT, bin2hex( fread(STDIN, 65536) ) );
};
break;
case '-d':
while (! feof(STDIN))
{
fwrite(STDOUT, pack( 'H*', fread(STDIN, 65536) ) );
};
break;
default:
$error = "Program $argv[0]\n";
$error .= " usage: cat infile | $argv[0] [-e|-d] > outfile\n";
$error .= " parameter: \n";
$error .= " -e encode (binhex)\n";
$error .= " -d decode (binhex)\n";
fwrite(STDERR, $error);
};
?>
Ich bin boeser Text!
[Dateiende]
Hi!
- das PHP-Programm soll die Standarteingabe STDIN lesen koennen
- das PHP-Programm soll in die Standartausgabe STDOUT schreiben koennen
- das PHP-Programm soll in die Fehlerausgabe STDERR schreiben koennen
- das PHP-Programm soll Paramter $argv auswerten koennen
Standard immer noch mit "d" am Ende. Ansonsten: Das PHP-Manual hat eine Suchfunktion. Hier mal die Ergebnisse für stdin.
Außerdem gibt es das Kapitel Using PHP from the command line, da steht alles schön zusammengefasst.
- Code der Ausserhalb con <?php ... ?> steht soll nicht ausgegeben werden
Der ist schon ausgegeben, wenn PHP erst danach aktiv werden kann. Wenn nach dem schließenden ?> nichts mehr außer dem Dateiende kommt, lass es weg, dann kann sich da nichts dazwischenschmuggeln. Ansonsten gibt es da nur noch die Output Control Functions, inklusive der php.ini-Option output_buffering. Kann aber sein, dass die bei CLI nicht mitspielt. Der Inhalt des Ausgabepuffers leert sich aber am Scriptende in Richtung Ausgabe. Beachte dazu den Parameter output_callback der Funktion ob_start().
Lo!
Hallo Lo,
... Das PHP-Manual hat eine Suchfunktion. Hier mal die Ergebnisse für
stdin.Außerdem gibt es das Kapitel
Using PHP from the command line, da steht alles schön zusammengefasst.
Wenn ich lesen könnte hätte ich vor meiner Anfrage bei http://de2.php.net...
und sonstwo nachgeschaut :-)
Im Ernst: in den eingschlägigen Dokus habe ich nichts gefunden. Sonst
würde ich wohl kaum die Anfrage schreiben. Den Workaround, das man vor
und hinter den PHP-Tag <?php ... ?> kein Byte schreiben darf, kann ich
nur schwer akzeptieren. Grund: Leerzeichen, Tab, etc. sind nicht sichtbar
und so kommt schnell ein Fehler rein der schwer zu finden ist.
Und wenn man eine Pipe aus mehreren PHP-Scripten baut, bei der ein PHP-
Script ungewollt ein Leerzeichen ausgibt, kann das zu erhebichen
Fehlern führen ...
Mit dem Problem kann ich doch nicht ganz alleine darsten - oder?
Hi!
Den Workaround, das man vor und hinter den PHP-Tag <?php ... ?> kein Byte schreiben darf, kann ich nur schwer akzeptieren.
Dann hast mit PHP das falsche Werkzeug ausgesucht. Es ist vorrangig als Template-Sprache für HTML-Dokumente erfunden worden, und so hat man nun mal das Problem, sich nicht im PHP-Modus zu befinden, wenn das Script startet und PHP in <?php ?> einrahmen zu müssen.
Grund: Leerzeichen, Tab, etc. sind nicht sichtbar und so kommt schnell ein Fehler rein der schwer zu finden ist.
Dafür kann man ja das schließende ?> am Dateiende weglassen. Das startende <?php ganz an den Anfang zu bekommen oder zumindest als zweite Zeile nach der Shebang sollte nicht das Problem darstellen. Ich wüsste nun nicht mehr, wo man dann noch ungewollte Leerzeichen haben kann.
Lo!
Hi!
Den Workaround, das man vor und hinter den PHP-Tag <?php ... ?> kein Byte schreiben darf, kann ich nur schwer akzeptieren.
Dann hast mit PHP das falsche Werkzeug ausgesucht. Es ist vorrangig als Template-Sprache für HTML-Dokumente erfunden worden, und so hat man nun mal das Problem, sich nicht im PHP-Modus zu befinden, wenn das Script startet und PHP in <?php ?> einrahmen zu müssen.
Da hast du zum guten Teil recht (ich habe mir die von dir vorgeschlagenen Dokus von meiner Mutter vorlesen lassen). Im Handbuch finde ich im Kapitel zum Komandozeilenaufruf aber keinen "das ist Pfui Hinweis" ... die Entwickler sehen also durchaus der Aufruf in Shellumgebung vor. Folglich müsste das beschriebene Problem auch ein Allerweltsproblem sein ...
Grund: Leerzeichen, Tab, etc. sind nicht sichtbar und so kommt schnell ein Fehler rein der schwer zu finden ist.
Dafür kann man ja das schließende ?> am Dateiende weglassen. Das startende <?php ganz an den Anfang zu bekommen oder zumindest als zweite Zeile nach der Shebang sollte nicht das Problem darstellen. Ich wüsste nun nicht mehr, wo man dann noch ungewollte Leerzeichen haben kann.
Ich hätte eine Fehlermeldung vom Interpreter erwartet, wenn er zum Dateiende kommt ohne ein ">?" gefunden zu haben. Dem ist nicht so! Dein Workaround funktioniert! Danke! Das hat mich auf die Idee gebracht, vor dem "?>" ein die() zu setzen. Das funktioniert auch und ist sauberer.
Lo!
Noch ein Nachtrag für diejenigen, die das selbst mal testen wollen:
Wenn man das PHP-Beispielscript in eine Datei tmp.php kopiert, die
Datei mit "chmod -x ./tmp.php" auf exec. setzt und dann folgends
Kommando absetzt ...
cat ./tmp.php | ./tmp.php -e | ./tmp.php -d
wird der Text von ./tmp.php ausgegeben. Das ist ein netter Test
ob es funktionert.