12
Unverständlicher Tokenizer in Klammern
Bei dem Versuch den Batch-Tokenizer (der eine Zeile in einzelne Teile zerlegt), dachte ich einem guten Modell zur Erklärung schon recht nah zu sein.
Aber dann habe ich, ein mir vollkommen unerklärliches Phänomen entdeckt.
Das es Probleme mit Labeln in Klammern gibt ist ja schon länger bekannt.
Bisher war ich der Meinung, das Label nur als letztes in einem Klammerblock verboten sind
aber dann bin ich auf einen Beitrag gestoßen, bei dem auch innerhalb eines Blocks ein Problem entsteht.
Dann habe ich noch ein wenig gespielt, und bin auf ein noch ungewöhlicheres Verhalten gestoßen
Ausgabe
Ohne Klammern ist das Verhalten normal, das Caret am Ende wird als Multiline ausgewertet, die nächste Zeile wird gelesen, da die aber leer ist wird das <LF> der leeren Zeile Escaped, damit ist kein Zeilenende mehr da und die nächste Zeile wird auch noch an das Multiline dran gehängt.
Varianten davon
Ausgabe
Aber wie kann man das verschwinden eines einzelnen Token in der Klammer erklären ?
jeb
Aber dann habe ich, ein mir vollkommen unerklärliches Phänomen entdeckt.
Das es Probleme mit Labeln in Klammern gibt ist ja schon länger bekannt.
Bisher war ich der Meinung, das Label nur als letztes in einem Klammerblock verboten sind
@echo off
(
:MeinLabel
echo Klappt
)
(
echo Klappt nicht
:MeinLabel
)aber dann bin ich auf einen Beitrag gestoßen, bei dem auch innerhalb eines Blocks ein Problem entsteht.
@echo off
(
echo start
:comment
:comment
echo KLAPPT
)
(
echo start
::comment
:comment
echo KLAPPT
)
(
echo start
:comment
::comment
echo KLAPPT nicht
)Dann habe ich noch ein wenig gespielt, und bin auf ein noch ungewöhlicheres Verhalten gestoßen
@echo off
(
:label eins zwei drei ^
WegIsses echo two three
echo Nur das erste Token ist weg
)
echo ---
(
:label eins zwei drei^
WegIsses echo two three
echo Jetzt ist es ganz weg
)
:label eins zwei drei ^
WegIsses echo two three
echo Ohne Klammer ist es immer wegAusgabe
two three
Nur das erste Token ist weg
---
Jetzt ist es ganz weg
---
Ohne Klammer ist es immer weg
Nur das erste Token ist weg
---
Jetzt ist es ganz weg
---
Ohne Klammer ist es immer weg
Ohne Klammern ist das Verhalten normal, das Caret am Ende wird als Multiline ausgewertet, die nächste Zeile wird gelesen, da die aber leer ist wird das <LF> der leeren Zeile Escaped, damit ist kein Zeilenende mehr da und die nächste Zeile wird auch noch an das Multiline dran gehängt.
Varianten davon
@echo off
setlocal EnableDelayedExpansion
echo Hallo ^
Dies zeigt einen Text mit Zeilenumbruch
echo -----
set lf=^
rem Zwei Leerzeilen sind wichtig, damit wird jetzt ein einzelnes LF erzeugt
rem Allerdings kann man ein LF nur mit DelayedExpansion ausgeben
echo Erste Zeile!LF!Zweite ZeileAusgabe
Hallo
Dies zeigt einen Text mit Zeilenumbruch
Erste Zeile
Zweite Zeile
Dies zeigt einen Text mit Zeilenumbruch
Erste Zeile
Zweite Zeile
Aber wie kann man das verschwinden eines einzelnen Token in der Klammer erklären ?
jeb
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 151317
Url: https://administrator.de/forum/unverstaendlicher-tokenizer-in-klammern-151317.html
Ausgedruckt am: 22.12.2024 um 12:12 Uhr
12 Kommentare
Neuester Kommentar
Hallo jeb,
unverständlich ist und bleibt das für mich auch.
Vielleicht liegt des Rätsels Lösung in der Art und Weise wie mit Zeilenumbrüchen in Multilines umgegangen wird.
Ausgabe:
Die Frage ist, woher kommen die Leerzeichen (hinter "Test" im ersten Beispiel bzw. vor dem zweiten echo im zweiten Beispiel). Werden Zeilenumbrüche tatsächlich als Leerzeichen interpretiert bzw. wird ein zusätliches Leerzeichen angehängt? Kann eigentlich nicht sein, denn die Erzeugung des Line Feed Characters würde auch im Multiline Block funktionieren.
Ausgabe:
Andererseits deutet einiges auf die Ersetzung des Zeilenumbruches hin. Ein Caret escapet ja normalerweise nur ein Zeichen. Der "normale" Zeilenumbruch besteht aber aus CR+LF. Zwei Zeichen, hmm...
Und wenn man sich die Erzeugung des LF Characters ansieht, käme ja noch ein zusätzliches CR dazu, das es zu escapen gilt.
Noch habe ich da auch keine Idee, wie man nachvollziehbar testen kann.
Grüße
rubberman
unverständlich ist und bleibt das für mich auch.
Vielleicht liegt des Rätsels Lösung in der Art und Weise wie mit Zeilenumbrüchen in Multilines umgegangen wird.
@echo off &setlocal &prompt ¯¯¯ &echo on
(
echo Test
)
(
echo Hallo
echo Test
)»»» (echo Test )
Test
»»» (
echo Hallo
echo Test
)
Hallo
Test@echo off &setlocal enabledelayedexpansion &prompt ¯¯¯ &echo on
(
set LF=^
)
echo a!LF!b»»» (set LF=
)
»»» echo a!LF!b
a
bUnd wenn man sich die Erzeugung des LF Characters ansieht, käme ja noch ein zusätzliches CR dazu, das es zu escapen gilt.
Noch habe ich da auch keine Idee, wie man nachvollziehbar testen kann.
Grüße
rubberman
Hat jetzt nicht wirklich mit diesem Thema zu tun sondern vielleicht eher ein allgemeinerer Kommentar:
Ich würde solche "fragwürdigen" Konstrukte wie Excape Zeichen am ende der Zeile und dergleichen einfach nicht benutzen. Da mach ich mit bei einer batch Datei lieber etwas ausführlicher und mehr Arbeit und dafür vermeide ich so Sachen ...
Ich würde solche "fragwürdigen" Konstrukte wie Excape Zeichen am ende der Zeile und dergleichen einfach nicht benutzen. Da mach ich mit bei einer batch Datei lieber etwas ausführlicher und mehr Arbeit und dafür vermeide ich so Sachen ...
Hallo miniversum.
Ich gebe dir ja Recht. Man muss es nicht nutzen, es gibt bessere Möglichkeiten. Aber das ist auch nicht der Sinn der Übung.
Es geht nur darum herauszufinden, wie cmd.exe solchen Code verarbeitet, um möglichst allgemeingültige Regeln davon abzuleiten. Das wiederum hilft, wenn irgendein Batchfile nicht so funktioniert, wie man es erwartet. Ggf. findet man dann den Grund und bestenfalls auch eine Lösung ...
Ich persönlich finde es sehr gut, dass sich mal jemand mit dieser "Grundlagenforschung" beschäftigt. Das Internet hat da so gut wie nichts parat.
Grüße
rubberman
Ich gebe dir ja Recht. Man muss es nicht nutzen, es gibt bessere Möglichkeiten. Aber das ist auch nicht der Sinn der Übung.
Es geht nur darum herauszufinden, wie cmd.exe solchen Code verarbeitet, um möglichst allgemeingültige Regeln davon abzuleiten. Das wiederum hilft, wenn irgendein Batchfile nicht so funktioniert, wie man es erwartet. Ggf. findet man dann den Grund und bestenfalls auch eine Lösung ...
Ich persönlich finde es sehr gut, dass sich mal jemand mit dieser "Grundlagenforschung" beschäftigt. Das Internet hat da so gut wie nichts parat.
Grüße
rubberman
Zitat von @miniversum:
Ich würde solche "fragwürdigen" Konstrukte wie Excape Zeichen am ende der Zeile und dergleichen einfach nicht
benutzen. Da mach ich mit bei einer batch Datei lieber etwas ausführlicher und mehr Arbeit und dafür vermeide ich so
Sachen ...
Ich würde solche "fragwürdigen" Konstrukte wie Excape Zeichen am ende der Zeile und dergleichen einfach nicht
benutzen. Da mach ich mit bei einer batch Datei lieber etwas ausführlicher und mehr Arbeit und dafür vermeide ich so
Sachen ...
Wenn man wissen möchte wie und warum etwas funktioniert, muss man sich eben Tests ausdenken die etwas über die inneren Strukturen verraten.
Ohne sowas würden wir noch in Höheln wohnen und die Erde für eine Scheibe halten(und den Batch Interpreter für einen Zufallsgenerator)
Zitat von @rubberman:
Andererseits deutet einiges auf die Ersetzung des Zeilenumbruches hin. Ein Caret escapet ja normalerweise nur ein Zeichen. Der
"normale" Zeilenumbruch besteht aber aus CR+LF. Zwei Zeichen, hmm...
Und wenn man sich die Erzeugung des LF Characters ansieht, käme ja noch ein zusätzliches CR dazu, das es zu escapen
gilt.
Andererseits deutet einiges auf die Ersetzung des Zeilenumbruches hin. Ein Caret escapet ja normalerweise nur ein Zeichen. Der
"normale" Zeilenumbruch besteht aber aus CR+LF. Zwei Zeichen, hmm...
Und wenn man sich die Erzeugung des LF Characters ansieht, käme ja noch ein zusätzliches CR dazu, das es zu escapen
gilt.
Das mit dem "verschwundenen" <CR> ergibt sich aus Phase1.1
Nach dem ersetzen der Prozent Phase, werden alle <CR> entfernt (Daher können die ja auch nur mit !CR! ausgegeben werden).
Daher klappt der LF Trick.
Als Test für das <CR> verschwinden
@echo off
cls
setlocal EnableDelayedExpansion
call :CreateCR
set "empty="
echo Eine %CR%Zeile1
echo Eine ^%CR%Zeile2
echo Eine ^%CR%&Zeile3
echo Leer ^%empty%& geht auch
echo Eine Laus oder doch !CR!eINE mAUS
goto :eof
::: Erzeugt ein einzelnes CR Zeichen in einer Variable
:CreateCR
setlocal EnableDelayedExpansion EnableExtensions
set "X=."
for /L %%c in (1,1,13) DO set "X=!X:~0,4093!!X:~0,4093!"
REM In X werden 8186 Punkte abgelegt, man kann aber auch was anderes nehmen
REM Jetzt muss genau die richtige Länge ausgegeben werden
REM Dann passt beim expandieren der Zeile und der anschliessenden Ausgabe das <CR><LF> nicht mehr in den Puffer
REM sondern nur noch das <CR>
echo !X!123 > %temp%\cr.tmp
REM Damit hinterher aber die Zeile komplett gelesen werden kann, noch direkt ein Extra <CR><LF> anhängen
echo\>> %temp%\cr.tmp
REM Jetzt noch die Datei einlesen, im ersten Token sind dann die Punkte im Zweiten das goldene <CR>
for /f "tokens=2 usebackq" %%a in ("%temp%\cr.tmp") do (
endlocal
set "cr=%%a"
goto :eof
)
REM Am Schluss noch ein goto :eof, falls es Probleme mit der Datei gab
goto :eofAusgabe
Eine Zeile1
Eine Zeile2
Eine &Zeile3
Leer & geht auch
eINE mAUS oder doch
Eine Zeile2
Eine &Zeile3
Leer & geht auch
eINE mAUS oder doch
Bei der letzten Zeile ist natürlich der gesamte Satz ausgegeben worden, aber durch das CR ist der Cursor halt wieder zum Zeilenanfang gesprungen.
jeb
Zitat von @jeb-the-batcher:
Wenn man wissen möchte wie und warum etwas funktioniert, muss man sich eben Tests ausdenken die etwas über die inneren
Strukturen verraten.
Ohne sowas würden wir noch in Höheln wohnen und die Erde für eine Scheibe halten(und den Batch Interpreter für
einen Zufallsgenerator)
1. Testest du das mit allen Windowsversionen und alles Servicepacks? Kannst du sicherstellen das sich nicht ab einem gewissen Versionsstand das Verhalten anders ist?Wenn man wissen möchte wie und warum etwas funktioniert, muss man sich eben Tests ausdenken die etwas über die inneren
Strukturen verraten.
Ohne sowas würden wir noch in Höheln wohnen und die Erde für eine Scheibe halten(und den Batch Interpreter für
einen Zufallsgenerator)
2. Würdest du nach deiner "Untersuchung" solche Konstrukte wirklich ruhigen Gewissens verwenden?
3. Was nützt dir diese "Untersuchung" undokumentierter Funktionen für die du keine Garantie hast das es nicht doch noch Ausnahmefälle geben wird die ein anderes Verhalten hervorrufen?
4. Praktischer nutzen?
Stimmt.
Was ist aber mit den (zumindest angezeigten) zusätzlichen Leerzeichen? Irgendetwas muss im Multiline Block anders laufen als sonst.
Grüße
rubberman
Was ist aber mit den (zumindest angezeigten) zusätzlichen Leerzeichen? Irgendetwas muss im Multiline Block anders laufen als sonst.
Grüße
rubberman
1. Ich teste mit den Versionen die ich habe, und ich gehe davon aus, dass auch bei Microsoft niemand etwas ohne guten Grund ändert.
2. Es geht mir nicht um die Konstrukte, mir geht es darum zu erklären warum man z.B. für verschiedene Sonderzeichen unterschiedliche Wege gehen muss um sie auszugeben.
Ohne Untersuchung, ist das bloß rumgerate.
3. Wie bei 2., es geht nicht um die undokumentierten Funktionen an sich, aber wenn ich den Parser verstehe, dann weiß ich auch was machbar ist und was eben nicht.
Du hast natürlich recht, bei den Grenzfällen kann man nicht davon ausgehen, dass die immer in allen Versionen funktionieren, weil das möglicherweise nicht gewollte sondern nur Nebeneffekte der Programmierung sind.
z.B. verhält sich
Es läßt sich naturbedingt hier nicht feststellen, ob es noch unentdecktes Verhalten gibt, dazu müßte man wirklich alles testen (und soviel Zeit habe ich grade nicht).
4. Wie in 2. und 3. beschrieben, Wissen über die genaue Syntax.
Und Forschung hat selten einen direkten praktischen Nutzen, sollte man es dann lieber direkt lassen?
Ich bin professioneller Ansi-C Programmierer, und kann mich noch an meine Anfangszeit erinnern, bei der ich Dinge übernommen habe ohne zu verstehen, warum die da so stehen, heute weiß ich bei jedem Ausdruck was der Compiler oder der Linker dazu denkt und daraus erzeugt.
Und wenn was nicht läuft kann ich herrausfinden ob mein Code einen Fehler hat oder der Compiler, früher konnte ich nur im Nebel stochern.
2. Es geht mir nicht um die Konstrukte, mir geht es darum zu erklären warum man z.B. für verschiedene Sonderzeichen unterschiedliche Wege gehen muss um sie auszugeben.
echo Zeig mir ein Prozent %%
echo Zeig mir ein Ampersand ^&
echo Zeig mir ein Ausrufezeichen ^^! 3. Wie bei 2., es geht nicht um die undokumentierten Funktionen an sich, aber wenn ich den Parser verstehe, dann weiß ich auch was machbar ist und was eben nicht.
Du hast natürlich recht, bei den Grenzfällen kann man nicht davon ausgehen, dass die immer in allen Versionen funktionieren, weil das möglicherweise nicht gewollte sondern nur Nebeneffekte der Programmierung sind.
z.B. verhält sich
set "caret=^"
call echo und jetzt ein Vista Crash %%caret%%
rem für Vista hilft nur ein Kill, XP dagegen ignoriert das Multiline beim zweiten Expandieren.4. Wie in 2. und 3. beschrieben, Wissen über die genaue Syntax.
Und Forschung hat selten einen direkten praktischen Nutzen, sollte man es dann lieber direkt lassen?
Ich bin professioneller Ansi-C Programmierer, und kann mich noch an meine Anfangszeit erinnern, bei der ich Dinge übernommen habe ohne zu verstehen, warum die da so stehen, heute weiß ich bei jedem Ausdruck was der Compiler oder der Linker dazu denkt und daraus erzeugt.
Und wenn was nicht läuft kann ich herrausfinden ob mein Code einen Fehler hat oder der Compiler, früher konnte ich nur im Nebel stochern.
Nur so ein Beispiel warum ich das Problematisch sehe. Dein Code:
ergibt bei mir (Windows xp pro mit sp3 und den aktuellen Updates) :
und
ergibt:
Also hast du hier anscheinend schon Unterschiede, nur mal als ein Beispiel.
Der Vergleich mit ANSI-C ist auch interessant weil ich selbst aus Erfahrung weiß das verschiedene (mehr oder weniger gute, aber angeblich immer ANSI konforme Compiler) den identischen C Code in unterschiedlichen Maschinencode umsetzen können, wenn es z.B. um Strukturen geht.
Das Argument
Und da Fehler und unerwartetes Verhalten in Batch Skripten erwiesenermaßen abhängig von der Version und der eingestellten Sprache ist (ja das ist bei einigen Befehlen wirklich so) und ich auch schon Unterschiede in Abhängigkeit vom Speicherort der Batch Datei (Lokal oder Netzwerkpfad) erlebt habe bevorzuge ich es eben solche "grenzwertigen" Konstrukte nicht zu benutzen und im Fehlerfall lieber das echo off bzw. an der betreffenden Stelle ein echo on einzufügen um zu sehen was wirklich geschieht.
echo Zeig mir ein Prozent %%
echo Zeig mir ein Ampersand ^&
echo Zeig mir ein Ausrufezeichen ^^! Zeig mir ein Prozent %
Zeig mir ein Ampersand &
Zeig mir ein Ausrufezeichen ^!echo Zeig mir ein Ausrufezeichen ^! Zeig mir ein Ausrufezeichen !Also hast du hier anscheinend schon Unterschiede, nur mal als ein Beispiel.
Der Vergleich mit ANSI-C ist auch interessant weil ich selbst aus Erfahrung weiß das verschiedene (mehr oder weniger gute, aber angeblich immer ANSI konforme Compiler) den identischen C Code in unterschiedlichen Maschinencode umsetzen können, wenn es z.B. um Strukturen geht.
Das Argument
1. Ich teste mit den Versionen die ich habe, und ich gehe davon aus, dass auch bei Microsoft niemand etwas ohne guten Grund ändert.
schließt ja nicht aus, dass mit einem bestimmtem Update dennoch eine Änderung dazu kommt, der Programmierer auch den Grund kennt, Du aber nicht.Und da Fehler und unerwartetes Verhalten in Batch Skripten erwiesenermaßen abhängig von der Version und der eingestellten Sprache ist (ja das ist bei einigen Befehlen wirklich so) und ich auch schon Unterschiede in Abhängigkeit vom Speicherort der Batch Datei (Lokal oder Netzwerkpfad) erlebt habe bevorzuge ich es eben solche "grenzwertigen" Konstrukte nicht zu benutzen und im Fehlerfall lieber das echo off bzw. an der betreffenden Stelle ein echo on einzufügen um zu sehen was wirklich geschieht.
...
Beim Ausrufenzeichen gibt es keinen Unterschied, ich habe nur vergessen das
mit anzugeben.
Und spätestens an der Stelle ist es dann doch recht hilfreich, wenn man versteht, warum man bei Ausrufezeichen zwei Carets benötigt, bei allen anderen aber nur eins, und warum man ein Prozent gar nicht mit Carets escapen kann.
ergibt:
Also hast du hier anscheinend schon Unterschiede, nur mal als ein Beispiel.
Zeig mir ein Ausrufezeichen !
> Also hast du hier anscheinend schon Unterschiede, nur mal als ein Beispiel.
Beim Ausrufenzeichen gibt es keinen Unterschied, ich habe nur vergessen das
setlocal EnableDelayedExpansionmit anzugeben.
Und spätestens an der Stelle ist es dann doch recht hilfreich, wenn man versteht, warum man bei Ausrufezeichen zwei Carets benötigt, bei allen anderen aber nur eins, und warum man ein Prozent gar nicht mit Carets escapen kann.
Der Vergleich mit ANSI-C ist auch interessant weil ich selbst aus Erfahrung weiß das verschiedene (mehr oder weniger gute,
aber angeblich immer ANSI konforme Compiler) den identischen C Code in unterschiedlichen Maschinencode umsetzen können, wenn
es z.B. um Strukturen geht.
Aber das ist ja auch kein Problem und durchaus erlaubt, wenn man die ISO/IEC-Norm gelesen hat, weiß man an welchen Stellen ein Ansi-C Compiler Freiheiten hat, und wodrauf man sich absolut verlassen kann (Sonst ist er halt nicht mehr ISO-konform).aber angeblich immer ANSI konforme Compiler) den identischen C Code in unterschiedlichen Maschinencode umsetzen können, wenn
es z.B. um Strukturen geht.
Ich hab ein wenig geforscht...
Und ich denke ich kann es jetzt halbwegs beschreiben.
In einem Klammerblock wirken sich label direkt auf die nächste Zeile aus.
Der erste Token der nächsten Zeile wird als Kommando betrachtet, was ja im allgemeinen ohnehin so ist.
Allerdings in diesem Fall ohne Ausnahme, sprich auch ein Label oder eine schliessende Klammer wird nur noch als Kommando gesehen.
Sprich, hier wird versucht ::label2 (beachte die zwei Doppelüunkte) auszuführen, was fehlschlägt
Dies schlägt komplett fehl weil keine schliessende Klammer gefunden wird(die wird als Kommando angesehen)
Das klappt allerdings
Und alle "geraden" Lableblöcke funktionieren
Der spannende Teil ist, wie die zweite Zeile interpretiert wird
jeb - immer auf der Suche
Und ich denke ich kann es jetzt halbwegs beschreiben.
In einem Klammerblock wirken sich label direkt auf die nächste Zeile aus.
Der erste Token der nächsten Zeile wird als Kommando betrachtet, was ja im allgemeinen ohnehin so ist.
Allerdings in diesem Fall ohne Ausnahme, sprich auch ein Label oder eine schliessende Klammer wird nur noch als Kommando gesehen.
Sprich, hier wird versucht ::label2 (beachte die zwei Doppelüunkte) auszuführen, was fehlschlägt
(
:label1
::label2
)Dies schlägt komplett fehl weil keine schliessende Klammer gefunden wird(die wird als Kommando angesehen)
(
echo 1
:label1
)Das klappt allerdings
(
echo 1
:label1
echo nix)Und alle "geraden" Lableblöcke funktionieren
(
echo 1
:label1a
:label1b
echo2
:label2a
:label2b
)Der spannende Teil ist, wie die zweite Zeile interpretiert wird
(
echo 1
:label der eine Sonderbehandlung der naechsten Zeile erzeugt
:\..\%~nx0&echo Und dadruch sehen wir dies
)jeb - immer auf der Suche
Erstaunlich ^^
Ähnliches hatte ich auch getestet, war aber mit dem Leerzeichen als vermeintlichen Übeltäter auf der falschen Fährte.
Der letzte Code endete bei mir erst mal in einem Fehler (Leerzeichen im Name
).
... schaffte Abhilfe.
Grüße
rubberman
Ähnliches hatte ich auch getestet, war aber mit dem Leerzeichen als vermeintlichen Übeltäter auf der falschen Fährte.
Der letzte Code endete bei mir erst mal in einem Fehler (Leerzeichen im Name
).(
echo 1
:label der eine Sonderbehandlung der naechsten Zeile erzeugt
:\..\%~snx0&echo Und dadruch sehen wir dies
)Grüße
rubberman
Der Effekt ist ja auch an sich erstaunlich,
es wird nach der Datei gesucht, aber gestartet wird sie nicht!
Einfacher ist es daher
Aber ganz zufrieden bin ich nicht.
Denn diesen Teil kann ich mir damit immer noch nicht richtig erklären
Bei deinen Leerzeichen könnte es sich um versuchte Formatierung handeln (gewollt aber nicht so richtig gekonnt), oder eben doch um einen Hinweis, wie Klammern ausgewertet werden.
jeb
es wird nach der Datei gesucht, aber gestartet wird sie nicht!
Einfacher ist es daher
(
:lab2
:&echo Einfache Ausgabe
:lab3
:: 2>nul
)Aber ganz zufrieden bin ich nicht.
(
:label eins zwei drei ^
WegIsses echo two three
echo Nur das erste Token ist weg
)
echo ---
(
:label eins zwei drei^
WegIsses echo two three
echo Jetzt ist es ganz weg
) Bei deinen Leerzeichen könnte es sich um versuchte Formatierung handeln (gewollt aber nicht so richtig gekonnt), oder eben doch um einen Hinweis, wie Klammern ausgewertet werden.
jeb
