Verschachtelte php-Routinen

[Rolli]

Hallo,
wie kann ich den erzeugten  Quelltext ansehen nach Auflösung von require (mit weiteren require darin).
Hintergrund:
Manchmal erhalte ich eine falsch Abfolge von <?php und ?>

[dedlfix]

Tach!

wie kann ich den erzeugten  Quelltext ansehen nach Auflösung von require (mit weiteren require darin).

Gar nicht. Das Script, in dem das require/include steht, ist bereits nur noch Bytecode. Der Rest nach dem require/include auch nur noch.

Manchmal erhalte ich eine falsch Abfolge von <?php und ?>

Die müssen (nur) innerhalb eine Dokuments konsistent sein (wobei das letzte ?> am Dateiende weggelassen werden kann).

dedlfix.

[Rolli]

Hi

Die müssen (nur) innerhalb eine Dokuments konsistent sein (wobei das letzte ?> am Dateiende weggelassen werden kann).

Innerhalb der einzelnen Dokumente oder des Gesamtdokuments?
Beispiel (shtml wird über .htaccess-Einstellung geparst):
a.shtml

  
<?php  
require ...b.shtml  
?>  

b.shtml

  
/* HTML-Text  
....  
*/  
<?php  
....  
?>  

a.shtml ist konsistent,
b.shtml ist konsistent
Es kommt aber der Fehler:
Parse error: syntax error, unexpected $end in ....

[bubble]

require ...b.shtml

Das sieht mir nach allem aus, aber nicht nach richtig.  
Ein (je nach dem ob a.shtml und b.shtml im gleichen verzeichnis liegen, und das Verzeichnis in dem sie liegen, dass aktuelle Arbeitsverzeichnis für PHP ist, davon gehe ich jetzt aus) `require "b.shtml";`{:.language-php} sollte das Problem lösen.  
Zeichenketten werden in Anführungszeichen gepackt à la "Ich bin eine Zeichenkette" oder 'Ich auch', desweiteren werden die einzelnen Befehle mit einem Semikolon beendet.  
Der Interpreter sucht hier quasi nach dem fehlenden ";" findet aber das Dateiende ($end) und kann garnicht erst meckern, dass ...b.shtml gar kein String ist.  
  
MfG  
bubble

[dedlfix]

Tach!

require ...b.shtml
Der Interpreter sucht hier quasi nach dem fehlenden ";" findet aber das Dateiende ($end) und kann garnicht erst meckern, dass ...b.shtml gar kein String ist.

Nein, die Erklärung passt nicht. Die "unexpected $end"-Fehlermeldung[1] würde nur dann kommen, wenn nach der require-Zeile kein Code mehr käme. Der Parser sucht nicht nach bestimmten Dingen sondern er parst einfach vor sich hin und schaut, ob das was da auftaucht, im gerade aktuellen Kontext sinnvoll ist oder nicht. Das fehlende Semikolon würde er nicht bemerken, stattdessen das irgendwas kommt, was nicht darf. Der Parser weiß auch gar nicht, wann konkret das Semikolon kommen muss, denn hier in dem Fall man kann den zu inkludierenden Dateinamen ja auch mit einem beliebig komplexen Ausdruck zusammenbauen. Aus diesem Grund sind Parser-Meldungen meist auch etwas wenig hilfreich, weil nicht da steht, wo der der Programmierer was vergessen hat, sondern irgendwo später, dass da was nicht stehen darf. Nach der Programmlogik ist vielleicht ganz richtig, was da steht, nur irgendwo vorher ist eben was falsch.

[1] In PHP4 heißt das endlich weniger irritierend "unexpected end of file".

dedlfix.

[dedlfix]

Tach!

[1] In PHP4 heißt das endlich weniger irritierend "unexpected end of file".

"PHP 5.4" sollte das werden.

dedlfix.

[bubble]

Tach!

require ...b.shtml
Der Interpreter sucht hier quasi nach dem fehlenden ";" findet aber das Dateiende ($end) und kann garnicht erst meckern, dass ...b.shtml gar kein String ist.

Nein, die Erklärung passt nicht. Die "unexpected $end"-Fehlermeldung[1] würde nur dann kommen, wenn nach der require-Zeile kein Code mehr käme.

<?php
require ...b.shtml
?>

Ist das nicht genau der Fall?

Wenn der Parser nicht zu erst das fehlende Semikolon bemerken würde, müsste er doch wegen dem '...b.shtml' meckern.

Ich vermute allerdings, dass ich grad voll auf dem Schlauch stehe :'D

MfG
bubble

[dedlfix]

Tach!

Die "unexpected $end"-Fehlermeldung[1] würde nur dann kommen, wenn nach der require-Zeile kein Code mehr käme.
<?php
require ...b.shtml
?>
Ist das nicht genau der Fall?

Ja, in dem Fall wäre das richtig, aber ich red mich mal so raus: Der OP hat nicht angegeben, in welcher der Datei der Fehler auftrat und vielleicht war es ja im Original richtig und nur falsch zitiert.

Wenn der Parser nicht zu erst das fehlende Semikolon bemerken würde, müsste er doch wegen dem '...b.shtml' meckern.

Wir nehmen mal an, dass der OP wirklich require foo.bar stehen hat, also den Dateinamen ohne Anführungszeichen. Der Parser weiß nicht, dass da ein Semikolon fehlt. Für PHP ist es kein wirklicher Fehler, wenn ein String nicht in Anführungszeichen steht. PHP wird zuerst versuchen, foo als Konstante aufzulösen. Gibt es keine solche, nimmt es an, man meinte einen String und dazu eine Notice werfen. Dann kommt der Punkt, der hier, weil er nicht innerhalb eines Stringliterals steht, als Stringverknüpfungsoperator wirkt. bar wird nach demselben Prinzip auch wieder ein String. Jedenfalls könnten nun noch weitere Stringverküpfungen folgen (egal ob mit oder ohne Anführungszeichen), auch in nachfolgenden Zeilen. Das muss der Parser ja auch korrekt erkennen können. Er darf also nicht nur nach dem Semikolon Ausschau halten. Und deshalb kann er auch nicht einfach sagen, dass dieses fehlt, es könnte ja auch ein Punkt fehlen. Die Programmierer haben nun in den Fehlermeldungen nicht alle Möglichkeiten angeführt, weil diese unter Umständen ziemlich viele sein können, stattdessen steht da nur "unerwartetes Einzelding".

dedlfix.

[bubble]

Und wieder etwas schlauer geworden :)
Danke für die ausführliche Erklärung.

MfG
bubble

[ichbinich]

Hallo,

was für eine Antwort erhoffst du dir bei so einem Code-Fetzen?

Entferne nacheinander die includes, sowie evtl. vorhandenen Code der direkt in der Seite steht und grenze dadurch den Fehler ein.

vg ichbinich

[dedlfix]

Tach!

Die müssen (nur) innerhalb eine Dokuments konsistent sein (wobei das letzte ?> am Dateiende weggelassen werden kann).
Innerhalb der einzelnen Dokumente oder des Gesamtdokuments?

Jedes einzeln. Es gibt kein Gesamt-Dokument. Der Code wird nicht erst zusammengefügt und dann geparst. Das geht schon deshalb nicht, weil man mit Bedingungen und mit Schleifen die Dateien in beliebiger erst zur Laufzeit bekannter Anzahl einbinden kann.

a.shtml ist konsistent,
b.shtml ist konsistent

Das ?> vor dem Dateiende kann wegbleiben. Das ist sogar ziemlich sinnvoll, weil sich dann danach kein Whitespace mehr einschleichen kann, das bereits die Ausgabe einleitet, woraufhin man keine HTTP-Header mehr ändern kann.

Es kommt aber der Fehler:
Parse error: syntax error, unexpected $end in ....

Du hast vermutlich einen Klammern- oder Stringfehler. Da ist irgendeine Struktur nicht geschlossen. Wenn mittendrin ein ?> fehlen würde, dann hätte sich PHP am HTML folgenden gestört.

dedlfix.

[Rolli]

Hallo

Du hast vermutlich einen Klammern- oder Stringfehler. Da ist irgendeine Struktur nicht geschlossen. Wenn mittendrin ein ?> fehlen würde, dann hätte sich PHP am HTML folgenden gestört.

Ja, wie ich jetzt festgestellt habe, liegt es nicht an der Verschachtelung - es muss viel trivialer sein. Aber obwohl ich die Texte x-mal durchgelesen habe finde ich den Fehler nicht - Blackout!
Wenn ich nachfolgende Scripts isoliert laufen lasse, ergeben sich unterschiedliche Ergebnisse:

  
<?php  
   echo <<<TXT  
   Hallo  
TXT;  
  
?>  

Ergebnis: Parse error: syntax error, unexpected $end in C:\test\p1.shtml on line 7
Hinweis: Nach TXT; kommt ein Zeilenumbruch

  
<?php  
  echo "Hallo";  
  
?>  

Ergebnis: Hallo

[Rolli]

Hallo!

Und jetzt die Erleuchtung!

Habe die Scripts bisher immer in proton editiert, da wurden die einzelnen Zeilen korrekt angezeigt. Zur Kontrolle habe ich es jetzt mit wordpad editiert, ebenfall in Ordnung aber ....
im Notepad steht alles in einer Zeile.
Also wohl der falsche Zeilenumbruch. (durch Copy and paste aus einer anderen Datei?)
Habe jetzt in Notepad mit der Zeilenumschaltung gearbeitet, und es klappt!
Aber wie kann ich das zukünftig vermeiden?
Welche Character in Windows sind die richtigen?

[dedlfix]

Tach!

im Notepad steht alles in einer Zeile.

Notepad kannst du komplett ignorieren. Besser ist Notepad++, der zeigt dir auch unten rechts an, welche Zeilenenden verwendet wurden (Dos\Windows vs. Unix). (Umformatieren übers Edit-Menü)

Also wohl der falsche Zeilenumbruch.

Nee, richtig sind \r\n und \n, aber notwendig ist nur \n. Notepad ist nur Windows-fixiert und kann nur \r\n richtig auswerten. Wenn nur \n dasteht, ignoriert er den.

Habe jetzt in Notepad mit der Zeilenumschaltung gearbeitet, und es klappt!
Aber wie kann ich das zukünftig vermeiden?
Welche Character in Windows sind die richtigen?

Wenn du nur mit Windows arbeitest, dann wäre das \r\n, aber auf Unixsystemen ergibt das keinen gesteigerten Wert und manchmal sogar Fehler, die man nicht gleich findet. Am besten ist, den PHP-Kram nur mit \n zu bezeilenenden, dann klappt das überall.

dedlfix.

[dedlfix]

Tach!

Ergebnis: Parse error: syntax error, unexpected $end in C:\test\p1.shtml on line 7

Der Fehler ist mit dem gezeigten Code nicht reproduzierbar, aber:

Hinweis: Nach TXT; kommt ein Zeilenumbruch

Auch davor muss einer kommen, und zwar unmittelbar (also ohne jegliche Einrückung).

dedlfix.

[Rolli]

Hallo,
ich hoffe das liest noch jemand!
Ich habe nach wie vor Probleme mit dem Zeilenwechselzeichen.
define ('NL', "\r\n"); bzw. define ('NL', "\n"); definieren ja den Zeilenwechsel.
Aber diese Definition gilt auch für alle aufgerufenen Routinen.
Nun benötige ich wenn ich HTML erzeuge <br> als Zeilenwechsel.
Ich habe daher das Zeilenwechselzeichen mit der Variablen $NL definiert,
einmal als
$NL="<br>";    -- akzeptiert
und einmal als
$NL=0x0D0x0A;  -- Formaler Fehler
bzw.
$NL=0x0A;

Wenn ich dann im letzten Fall
"aaaaaa" . $NL . "bbbbbb" in eine Datei schreibe, so erscheint dort
aaaaa10bbbbb.
Wie muss ich das Newlinezeichen (\r\ bzw \n in einer Variablen definieren?

[Kai345]

[latex]Mae  govannen![/latex]

ich hoffe das liest noch jemand!
Ich habe nach wie vor Probleme mit dem Zeilenwechselzeichen.
define ('NL', "\r\n"); bzw. define ('NL', "\n"); definieren ja den Zeilenwechsel.
Aber diese Definition gilt auch für alle aufgerufenen Routinen.
Nun benötige ich wenn ich HTML erzeuge <br> als Zeilenwechsel.
einmal als
$NL="<br>";    -- akzeptiert
und einmal als
$NL=0x0D0x0A;  -- Formaler Fehler
bzw.
$NL=0x0A;

Weshalb benutzt du nicht nutze die passende Funktion NiederlandeZuBrasilien?

Stur lächeln und winken, Männer!
Kai

[dedlfix]

Tach!

Ich habe nach wie vor Probleme mit dem Zeilenwechselzeichen.
define ('NL', "\r\n"); bzw. define ('NL', "\n"); definieren ja den Zeilenwechsel.

Nö, die definieren die Konstante NL, mal mit Windows- mal mit Unix-Zeilenumbruch als Inhalt.

Aber diese Definition gilt auch für alle aufgerufenen Routinen.

Nö, sie gilt für nichts. Es ist eine Konstante, die man verwenden kann oder auch nicht. Konstanten sind jedoch sozusagen superglobal, also wie beispielsweise $_GET und $_POST ohne weiteres Zutun überall verfügbar.

Nun benötige ich wenn ich HTML erzeuge <br> als Zeilenwechsel.
Ich habe daher das Zeilenwechselzeichen mit der Variablen $NL definiert,
einmal als
$NL="<br>";    -- akzeptiert
und einmal als
$NL=0x0D0x0A;  -- Formaler Fehler

0x0D ist ein Literal für eine Zahl in Hexdarstellung. Zwei solche aneinandergereiht ergibt keinen Sinn. Das wäre quasi wie 42 und 23 ohne Operator hintereinandergeschrieben, wenn das nicht als eine einzige Zahl (4223) aufgefasst würde. Hex-Zahlen fangen mit 0x an und dann folgen beliebig viele Ziffern 0-9 und a-f (Großbuchstaben für X und A-F sind auch zulässig). Du hast da 0x0D0 notiert und dann kommt ein x, was ein Syntaxfehler ist. Richtig wäre 0x0D0A. Aber das nützt dir nichts, weil dadurch nur die Zahl 3338 entsteht und kein String (var_dump($NL)). Wenn du diese Zahl in einen Stringkontext bringst, macht PHP seine automatische Typumwandlung von Zahl nach String und im String stehten dann die Zeichen '3338' und kein Zeilenumbruch.

bzw.
$NL=0x0A;

Daselbe in Grün, nur mit richtiger Hex-Zahlen-Syntax.

Wenn ich dann im letzten Fall "aaaaaa" . $NL . "bbbbbb" in eine Datei schreibe, so erscheint dort aaaaa10bbbbb.

Du könntest die Konstante NL statt der Variable $NL nehmen. Der Inhalt von $NL soll sich doch sicherlich nicht ändern, also ist eine Konstante semantisch besser als eine Variable. (Variablen lassen sich zwar einfacher in "Strings $NL notieren", sind aber nur Scope-abhängig verfügbar.)

Wie muss ich das Newlinezeichen (\r\ bzw \n in einer Variablen definieren?

Wenn du String unter Angabe des (ASCII-)Codes eines Zeichens erzeugen möchtest, musst du einen String anfangen und darin die Escape-Sequenz für hexadezimal notierte Zeichen-Codes nehmen: Strings - double quoted. Einfacher ist es aber so wie bei der Konstantendefinition, als \r\n innerhalb eines String-Literals.

dedlfix.

[Sven Rautenberg]

Moin!

Hallo,
ich hoffe das liest noch jemand!
Ich habe nach wie vor Probleme mit dem Zeilenwechselzeichen.
define ('NL', "\r\n"); bzw. define ('NL', "\n"); definieren ja den Zeilenwechsel.

PHP hat da schon eine Konstante vordefiniert: PHP_EOL enthält den für die Plattform, auf der es läuft, zuständigen Zeilenwechsel. Ohne dass man sich überlegen muss, ob man auf Windows oder Linux läuft.

Aber diese Definition gilt auch für alle aufgerufenen Routinen.
Nun benötige ich wenn ich HTML erzeuge <br> als Zeilenwechsel.

Wie gut, dass es da eine Funktion gibt, die das erledigt: nl2br() macht aus Zeichenketten mit Zeilenschaltungen Zeichenketten mit Zeilenschaltungen und <br/>.

Ich habe daher das Zeilenwechselzeichen mit der Variablen $NL definiert,
einmal als
$NL="<br>";    -- akzeptiert
und einmal als
$NL=0x0D0x0A;  -- Formaler Fehler
bzw.
$NL=0x0A;

Wenn ich dann im letzten Fall
"aaaaaa" . $NL . "bbbbbb" in eine Datei schreibe, so erscheint dort
aaaaa10bbbbb.
Wie muss ich das Newlinezeichen (\r\ bzw \n in einer Variablen definieren?

Genauso, wie bei der Definition von Konstanten.

Ich würde aber mal fragen wollen, welchen Effekt du damit erreichen willst, bzw. welches Problem du zu lösen gedenkst. Ich würde pauschal davon ausgehen, dass beide Plattformen mit den Zeilenschaltungen der jeweils anderen umgehen können, und würde das nur dann als ein zu programmierendes Problem ansehen, wenn du irgendwelche Dateien für unwissende Kunden erzeugst. Aber NICHT, wenn du nur irgendwelche internen Daten abspeichern willst. Denn PHP kann prima auch unter Windows mit Linux-Zeilenenden umgehen. Und auch Windows-Browser können das. :)

- Sven Rautenberg