DOS-Batch: verstümmelter Wert in lokaler Variable?

[cppbert (Gast)]

ich hab hier bei einem Kunden viele DOS-Batch Dateien von denen einige 
irgendwie nicht ganz so richtig funktionieren (mein Plan ist die 
komplette Umstellung der Batch-Dateien auf Python, das kommt aber erst 
später)

Jetzt habe ich ein Szenario bei dem einen in einem If gesetzte Variable 
nicht so vollständig ist wie ausserhalb eines Ifs

Das Batch-Beispiel:

@echo off
echo 1 ProgramFiles(x86): %ProgramFiles(x86)%
set x=1
if x == 1 (
  set PROGRAM_FILES_DIR=%ProgramFiles(x86)%
)
set PROGRAM_FILES_DIR2=%ProgramFiles(x86)%
echo 2 PROGRAM_FILES_DIR: %PROGRAM_FILES_DIR%
echo 3 PROGRAM_FILES_DIR2: %PROGRAM_FILES_DIR2%

Ausgabe:

1 ProgramFiles(x86): C:\Program Files (x86)
2 PROGRAM_FILES_DIR: C:\Program Files (x86
3 PROGRAM_FILES_DIR2: C:\Program Files (x86)

Warum unterscheidet sich die Ausgabe in Zeile 2 - am Ende fehlt ")" -
von der Ausgabe in Zeile 3?

[Mario M. (thelonging)]

Der Interpreter hält die schließende Klammer für das Ende der 
IF-Anweisung. Versuchs mal so:

if x == 1 (

  set "PROGRAM_FILES_DIR="%ProgramFiles(x86)%"

)

[Schlaumaier (Gast)]

Leerzeichen sind in DOS immer böse weil DOS alles was danach kommt als 
Parameter sieht. Also würde ich grundsätzlich ALLES in " " setzen.

[cppbert (Gast)]

Mario M. schrieb:
> Der Interpreter hält die schließende Klammer für das Ende der
> IF-Anweisung. Versuchs mal so:if x == 1 (
>   set "PROGRAM_FILES_DIR="%ProgramFiles(x86)%"
> )

ich hasse DOS-Batch:

nach deinem Tip sieht es nicht anders aus:

hab noch den x EQU x eingbaut damit das if immer evaluiert wird

@echo off
echo 1 ProgramFiles(x86): %ProgramFiles(x86)%
set x=1
if x EQU x (

  set PROGRAM_FILES_DIR=%ProgramFiles(x86)%
  
)
set PROGRAM_FILES_DIR2=%ProgramFiles(x86)%
echo 2 PROGRAM_FILES_DIR: %PROGRAM_FILES_DIR%
echo 3 PROGRAM_FILES_DIR2: %PROGRAM_FILES_DIR2%

Ausgabe

1 ProgramFiles(x86): C:\Program Files (x86)
2 PROGRAM_FILES_DIR: C:\Program Files (x86
3 PROGRAM_FILES_DIR2: C:\Program Files (x86)

ich verstehe nicht wie man es mit so einem Müll so weit treiben kann

[cppbert (Gast)]

mit Hochkommas geht es - aber warum das Problem nur auf den If-Block 
begrenzt ist kann bestimmt nur Microsoft erklären :)

@echo off
echo 1 ProgramFiles(x86): %ProgramFiles(x86)%
set x=1
if x EQU x (
  set PROGRAM_FILES_DIR="%ProgramFiles(x86)%"
)
set PROGRAM_FILES_DIR2="%ProgramFiles(x86)%"
echo 2 PROGRAM_FILES_DIR: %PROGRAM_FILES_DIR%
echo 3 PROGRAM_FILES_DIR2: %PROGRAM_FILES_DIR2%

Ausgabe:

1 ProgramFiles(x86): C:\Program Files (x86)
2 PROGRAM_FILES_DIR: "C:\Program Files (x86)"
3 PROGRAM_FILES_DIR2: "C:\Program Files (x86)"

[Schlaumaier (Gast)]

cppbert schrieb:
> mit Hochkommas geht es - aber warum das Problem nur auf den If-Block
> begrenzt ist kann bestimmt nur Microsoft erklären :)

Das kann ich dir sogar erklären. ;)

MS hängt an alten Strukturen.  Es ist schon ein Wunder das 16 !! 
Bit-Programme unter Win-10 nicht mehr laufen.

Der Interpreter des CMD (dos) ist deshalb aus Kompatibilitätsgründen 
niemals geändert worden.

Und als DOS auf die Welt kam, waren 8 Zeichen + 3 Extend normal. Und 
Leerzeichen galten als Trennzeichen zwischen Befehl (Prg) und seinen 
Parametern.

Dies hat sich bisher nicht geändert.

Irgendwann blickte man aber nicht mehr durch mit der 8+3 Regel. Also hat 
man einfach die Datei-Namesgebung erweitert. Was bedeutet das DOS einige 
WINDOWS -Versionen lang 2 Dateinamen im Dateinamen hatte. Diese ist 
sogar heute noch intern so.  mein_prgname.exe = mein_p~1.exe  und der 
richtige Name steht in der Erweiterung.

Unter heutigen Zeiten erkennt man dies nur noch an Undelete Software.

MS-Politisch gesehen sieht es so aus.  MS behauptet immer "Das gilt nur 
für die neusten Versionen". Diese Aussage ist aber reinste 
Marketingstrategie und hat mit der Realität nix  zu tun.

95 % aller Fixes, Tricks, Einstellungen etc. gelten bis Win-2000 
herunter genau so.

Windows ist halt einfach ein Historisch gewachsenes Flickwerk mit immer 
neuen Design und besserer Spionage-Software.

So einfach ist das.

[nicht"Gast" (Gast)]

na ja, wenn man alten Kram benutzt, dann ist das auch kein Wunder. 
Versuch mal die PowerShell. Die ist um einiges mächtiger als das blöde 
cmd.

Grüße

[Hel S. (zipp)]

Hmmm,

@echo off
echo 1 ProgramFiles(x86): %ProgramFiles(x86)%
set x=1

if x == 1 (
  set PROGRAM_FILES_DIR=%ProgramFiles(x86)%
  set PROGRAM_FILES_DIR=%ProgramFiles(x86)%
)

set PROGRAM_FILES_DIR2=%ProgramFiles(x86)%
echo 2 PROGRAM_FILES_DIR: %PROGRAM_FILES_DIR%
echo 3 PROGRAM_FILES_DIR2: %PROGRAM_FILES_DIR2%

... so funktionierts...

[cppbert3 (Gast)]

@Hel S.

Wirklich beängstigend... welcher wahnsinnige hat das entwickelt, kamen 
die if else konstrukte nicht erst nach den echte DOS Zeiten?

ich muss schleunigst auf Python wechseln, dann sind auch die Linux 
Shellscripts die noch so rumkreuchen auch gleich mit abgefrühstückt

[... (Gast)]

> auf Python wechseln

Das ist doch ein genauso zusammengewuerfelter Haufen Kaese.

Wenn du schon die simple Syntax von einem CMD nicht raffst,
was willst du dann mit diesem syntaktischen Versatzstueck?

Hier nochmal was zum ueben:

awk "BEGIN{print(strftime("""%%Y%%m%%d%%H%%M""",systime()))}"
FOR /F "usebackq" %%I IN ( `awk "BEGIN{print(strftime("""%%Y%%m%%d%%H%%M""",systime()))}"` ) DO @set VAR=%%I

[cppbert3 (Gast)]

... schrieb:
> Wenn du schon die simple Syntax von einem CMD nicht raffst,

dann erklär du doch mal genau warum bei Hel S. Beispiel das richtige 
Ergebnis raus kommt? Das Verhalten würde ich bei einer neuen Sprache 
ohne die Historie als Bug bezeichnen

ausser das es bei Windows schon dabei ist gibt es nur Nachteile 
gegenüber anderen Sprachen, Fehlererkennung ist z.B. so gut wie gar 
nicht vorhanden

Ich für meinen Teil würde alle Scripts einfach nach C++ portieren, 
sowieso die Projektsprache und die Script werden nur von Entwicklern 
verwendet und sehr sehr selten geändert, aber Python ist für eine 
einfach Windows, Linux Gleichbehandlung auch ausreichend und wird auch 
an anderen schon Stellen verwendet

[cppbert3 (Gast)]

... schrieb:
> Hier nochmal was zum ueben:
> awk "BEGIN{print(strftime("""%%Y%%m%%d%%H%%M""",systime()))}"
> FOR /F "usebackq" %%I IN ( `awk
> "BEGIN{print(strftime("""%%Y%%m%%d%%H%%M""",systime()))}"` ) DO @set
> VAR=%%I

auch wenn du für die paar Zeilen ganz sicher die "Goldene 
Ehrenanstecknadel der Shellprogrammierung" deiner Abteilung erhalten 
hast ist ausser der awk Parametrisierung die For Schleife so aber dann 
leider nicht Linux kompatibel und es geht mir eben auch ein bisschen um 
die Portierbarkeit

[Mario M. (thelonging)]

cppbert schrieb:
> warum das Problem nur auf den If-Block
> begrenzt ist kann bestimmt nur Microsoft erklären

Auch wenn Klammern in Dateinamen gültige Zeichen sind, haben sie in 
Batchdateien eine besondere Bedeutung. Die IF-Anweisung erkennt die 
letzte Klammer im Variablen-Wert fälschlicherweise als schließende 
Klammer der IF-Anweisung und "schluckt" sie. Als muss man sie "escapen", 
z.B. durch Anführungszeichen. Oder man lässt die Klammern einfach weg. 
;-)
Dass Hel S.' Beispiel  "funktioniert" liegt daran, dass die zweite 
Zuweisung durch obigen Bug eigentlich außerhalb des IF-Bereichs liegt 
und immer ausgeführt wird.
Im übrigen enthält der Code im Start-Post den Fehler, dass die Variable 
in der IF-Anweisung nicht in Prozent-Zeichen eingeschlossen ist.

Folgender Code tut, was er soll:

@echo off
echo 1 ProgramFiles(x86): %ProgramFiles(x86)%
set x=1
if %x% == 1 set PROGRAM_FILES_DIR=%ProgramFiles(x86)%
set PROGRAM_FILES_DIR2=%ProgramFiles(x86)%
echo 2 PROGRAM_FILES_DIR: %PROGRAM_FILES_DIR%
echo 3 PROGRAM_FILES_DIR2: %PROGRAM_FILES_DIR2%

[cppbert (Gast)]

Mario M. schrieb:
> Die IF-Anweisung erkennt die
> letzte Klammer im Variablen-Wert fälschlicherweise als schließende
> Klammer der IF-Anweisung und "schluckt" sie. Als muss man sie "escapen",
> z.B. durch Anführungszeichen.

das war auch meine Vermutung die hier teilweise ja schon bestätigt wurde

> Oder man lässt die Klammern einfach weg. ;-)

in meinem echten Code kommt da noch eine Else

> Dass Hel S.' Beispiel  "funktioniert" liegt daran, dass die zweite
> Zuweisung durch obigen Bug eigentlich außerhalb des IF-Bereichs liegt
> und immer ausgeführt wird.

das hab ich mir heute früh mit einem echo bestätigt

> Im übrigen enthält der Code im Start-Post den Fehler, dass die Variable
> in der IF-Anweisung nicht in Prozent-Zeichen eingeschlossen ist.

habe ich im 2. Post ja gefixt - ich wollte nur irgendwie ein if(true) 
machen

Allgemein hat die Syntax ziemlich viele kleine Lücken und alles wirkt 
ein wenig gebastelt, oder?

Würdest du sagen das ist ein gutes Design so wie Microsoft das gemacht 
hat? Solche Probleme kann man doch nicht mal wenn man will so einfach 
mit Powershell, Bash oder Python provozieren

[Mario M. (thelonging)]

Batch-Verarbeitung wurde auf Wunsch von IBM in PC-DOS 1.0 aufgenommen. 
Böse Zungen behaupten, es sei über den Zustand eines schlechten Hacks 
nie hinaus gekommen. ;-)

[rdp (Gast)]

Komische Assagen...
cppbert schrieb:
> Allgemein hat die Syntax ziemlich viele kleine Lücken und alles wirkt
> ein wenig gebastelt, oder?

Nö.
Das ist eine Stapelverarbeitungs-Skript-Sprache, gebastelt ist
Dein "Programm"-script.

Dein "Programm" ist fehlerhaft und Du hältst Dich einfach nur
nicht an die Regeln des script-Interpreters!

Die erste Regel einer Skript-Sprache ist:
Wenn ein Syntax entsteht, den der Skript-Interpreter als
script-Befehl interpretieren kann, dann sage dem Interpreter
"das ist jetzt gerade kein Befehl".
Grundlage: Informatik-"Projektgruppe" 8. Klasse: Syntax befolgen

Wenn Du da schon bei so einem einfachen "Problem" große Töne
mit/durch:
Microsoft macht Fehler,
alles sehr alt/komisch,
kann man besser machen...
anführst, was soll es dann erst bei dem "Umsetzen" per Python werden.

cppbert schrieb:
> ich verstehe nicht wie man es mit so einem Müll so weit treiben kann
Lerne bitte zu verstehen, wie und was eine Skript-Sprache ist
und warum z.B. ein Skript-Interpreter selten ein
"Syntax-Highlighting/-Tester" seien kann.

[Schlaumaier (Gast)]

Es heißt BATCH NICHT  Script-Programmierung.

Batch = Stapelverarbeitung.

Das die zufällig IF kann, ist irrelevant.

Als die entwickelt wurde, waren solche Dateinen üblich.

cls
c:\
cd\word
word


das ganze wurde als Datei w.bat in ein Verzeichnis "bat" abgelegt. Das 
Verzeichnis BAT wurde in der Autoexec.bat mit den PFAD Befehl als 
gloaler Zugriffspfad deklariert.

Der User (nix klicki-bunti) der nach Beenden irgendeiner Software nix 
anderes hatte als ein Blinkenden Strich auf den Bildschirm, konnte so 
schnell sein anders Programm starten. In meinen Beispiel reichte egal wo 
man war  W + Enter-Taste. So was habe ich damals Stress mässig 
eingerichtet.

ZU MEHR WAR DAS NIE ERFUNDEN WORDEN.

Aber wie so üblich, machen die aus jeder Software eine 
Eierlegendewollmilchsau.

Und dann herum meckern wenn man die seltsame Syntax nicht versteht, 
besonders wenn man eine 80er Jahre Technik unter Windows-10 nutzt.
Das sind übrigens die selben Leute, die ein Programmierer anmeckern, der 
sein Basic mag. Bloß der bekommt mit der WEITERENTWICKELTEN Software 
alles hin was er will.

Aktuell übrigens eine kleine Zeiterfassungs-Software weil den Kunden die 
Kauf-Software nicht gefällt.

au au au au.

[rdp (Gast)]

Na Du immer erst noch...
Was hat das mit dem Problem an sich zu tun?

Es ist ein Kommandozeilen-Interpreter der das
script/die Datei/das Batch ausführt.

Alles andere ist unzusammenhangmäßige "Luft"...

[cppbert (Gast)]

rdp schrieb:
> Komische Assagen...
> cppbert schrieb:
>> Allgemein hat die Syntax ziemlich viele kleine Lücken und alles wirkt
>> ein wenig gebastelt, oder?

die Bash hat solche Problem nicht und das Fehlerfeedback ist auch klarer

[cppbert (Gast)]

Ich bin wirklich ernsthaft erstaunt das sich hier Leute finden welche 
die miese Qualität der Windows-Stapelverarbeitung auch noch verteidigen, 
egal was ich für einen Bockmist gemacht habe ist das trotzdem zu viel 
des Lobes, Hut ab

[Peter Panda2 (Gast)]

wie gut das es ist wie es ist.
Gerade am WE hatte ich mir mal wieder Linux angesehen.
Frickelware, nachw ie vor.
Lubuntu war nach mehreren Installationsversuchen nicht auf einem Acer TM 
B zu installieren wegen Uefi vermutlich.
O Ton im Ubuntu Forum..bekanntes Problem..wenn es nicht gehet, geht es 
meist gar nicht...


Komisch ist das Linus selber sagt, wenn man mit Linux arbeiten will, 
muss man Lust und Zeit haben sich oft mit dem System zu beschäftigen und 
man darf nicht auf spezielle Programme angewiesen sein.

Nur die Anhänger behaupten seltsamerweise immer das alles super läuft, 
man nicht frickeln muss, weniger Zeit benötigt und für alles 
Alternativen gäbe..

Ne ist klar..
Microsoft ist nicht umsonst wo es ist..und Linux auch...

[cppbert (Gast)]

Peter Panda2 schrieb:
> wie gut das es ist wie es ist.
> Gerade am WE hatte ich mir mal wieder Linux angesehen.

was auch immer dein Schmerz ist - ich verwende die Bash auch unter 
Windows - ist nur ein Programm

[Peter Panda2 (Gast)]

"was auch immer dein Schmerz ist " Linux.... nicht schwer zu verstehen 
-oder?
Oder einige spielen hier auf die Nachteile von MS an.
Jetzt hast du es sicher auch verstanden

[cppbert (Gast)]

Peter Panda2 schrieb:
> "was auch immer dein Schmerz ist " Linux.... nicht schwer zu
> verstehen
> -oder?
> Oder einige spielen hier auf die Nachteile von MS an.
> Jetzt hast du es sicher auch verstanden

hier wurde gar nicht auf die Nachteile von MS angespielt - nur das die 
Oldschool-Stapelverarbeitung jetzt nicht gerade Supertoll ist, aber es 
gibt ja x alternativen für und von Microsoft die das lösen - und es ging 
auch überhaupt nicht um Windows/Linux- bei meinem Kunden sind es eh 
beide Systeme also kann ich mir den Luxus der freien Betriebssystem-Wahl 
eh nicht erlauben und muss eben mit dem bösen Linux genau so viel 
kämpfen wie du :)

[Udo S. (urschmitt)]

cppbert schrieb:
> was auch immer dein Schmerz ist - ich verwende die Bash auch unter
> Windows - ist nur ein Programm

Und warum machst du es dann nicht?

Willst du jetzt dein Problem lösen oder ist das nur ein Vorwand zu einem 
"böses Microsoft" Thread.

p.s. Ich finde alle Skriptsprachen furchtbar kryptisch und beschissen zu 
lesen.
Spass macht keine davon, aber manchmal muss man sie halt benutzen.

[rdp (Gast)]

cppbert schrieb:
> Ich bin wirklich ernsthaft erstaunt...

Andersrum wird doch da ein Hut daraus:
Hättest Du nicht
> ... einen Bockmist gemacht
brauchtest Du nicht die
> ... die miese Qualität der Windows-Stapelverarbeitung
als DEINE Entschuldigung anführen!
Denn das 'bisschen Dateikram' kann ja "sogar" die
command.com/cmd.com.

Sorry, aber Dein o.g. 'verstümmelter Wert in lokaler Variable'
ist bei command.com/cmd.com eben der klassische Fehler
(ICH schreibe da 'ne bat...) und eben die letzten 20 Jahre
immer wieder gemacht und 1000-fach erläutert...

Kommandozeileninterpreter gibt es wie Sand am Meer,
selbst für DOS, unter Windows 10 kannst Du WSL mit
Bash nutzen...
Nur,
nichts davon ändert etwas daran, deren Syntax und deren
Arbeitsweise (und deren Funktionsumfang) zu beachten!

https://de.wikipedia.org/wiki/Kommandozeileninterpreter

[cppbert (Gast)]

Udo S. schrieb:
> Und warum machst du es dann nicht?

ich war bei einem neuen Kunden und nach einer Weile ist mir der obige 
"Bug" in einem seiner vielen Scripts aufgefallen - ich wollte nur den 
Fehler genau verstehen, kurz fixen und später das ganze auf eine 
Windows/Linux-einheitliche Python Basis portieren weil die Sprache in 
anderen Teilen des Kunde-Projektes scheinbar schon eingesetzt wird

Das habe ich fast alles geschrieben - nur die meisten lesen eben nicht 
sondern fangen an über meine Beweggründe oder Erfahrungshintergrund zu 
fabulieren bis hin zu Linux/Windows Bashing... ist hier ja oft so wenn 
die Themen auch fürs einfache Volk geeignet sind :)

[🐧 DPA 🐧 (Gast)]

Peter Panda2 schrieb:
> wie gut das es ist wie es ist.
> Gerade am WE hatte ich mir mal wieder Linux angesehen.
> Frickelware, nachw ie vor.
> Lubuntu war nach mehreren Installationsversuchen nicht auf einem Acer TM
> B zu installieren wegen Uefi vermutlich.

Meine Installationserfolgsquote ist bei Linux bei weitem höher als bei 
Windows. Mit glück bekommt man bei Win noch den boot screen zu sehen, 
auf den Systemen crasht's dann dort und versucht's nochmal... Manchmal 
geht auch nur der Installer, aber das installierte System startet 
nicht... Und bei den paar wenigen Geräten, wo es immerhin startet, 
fehlen dann die Herstellerangepassten Treiber, und nichts geht 
richtig... Ja, das sind alles Windows Probleme.

[Schlaumaier (Gast)]

cppbert schrieb:
> Ich bin wirklich ernsthaft erstaunt das sich hier Leute finden welche
> die miese Qualität der Windows-Stapelverarbeitung auch noch verteidigen,
> egal was ich für einen Bockmist gemacht habe ist das trotzdem zu viel
> des Lobes, Hut ab

Es ist Corona-Zeit. Da schützen wir alte Leute  und alte Programme. Das 
Teil ist max. noch einmal durch ein Compiler gejagt worden, das ist 
alles.

[Schlaumaier (Gast)]

Udo S. schrieb:
> Spass macht keine davon, aber manchmal muss man sie halt benutzen.

Gebe ich dir völlig recht.

Ich habe z.b. eine Batch-Datei mit nur einen Befehl auf meine Desktop 
verlinkt. Die ist für mich als geplagter User und auch besonders ein 
Programmieren sehr sehr wichtig.

Hier der Befehl :   taskkill /F /IM excel.exe /T

Der löscht sämtliche offene Excel-Versionen die sich im Speicher 
herumtreiben. Wird nämlich jedes mal eine mehr wenn ich ein 
Programmfehler mache beim öffnen der OLE-Steuerung von Excel o. wenn 
Excel mal wieder abstürzt.

Für SO WAS sind Batch-Dateien bin in die heute modernste Zeit gut.

Oder wenn du über die Aufgabenplanung gewisse Jobs machst. z.B. eine 
Datenbank sichern und dann updaten Nachts wenn du schläfst.

Rechner geht an, macht sein Update und geht wieder aus. Und das obwohl 
der Coder der Software wollte das ich dabei bin ;)

Das sind nur einige Beispiele. Und dafür reicht eine ca. 40 Jahre alte 
Software völlig aus.

[spiderman (Gast)]

Schlaumaier schrieb:
> Als die entwickelt wurde, waren solche Dateinen üblich.
> cls
> c:
> cd\word
> word
> das ganze wurde als Datei w.bat in ein Verzeichnis "bat" abgelegt. Das
> Verzeichnis BAT wurde in der Autoexec.bat mit den PFAD Befehl als
> gloaler Zugriffspfad deklariert.

Du bist der typische Poweruser.

[Peter D. (peda)]

Ich komme mit dem Batchmode der CMD.EXE sehr gut zurecht. Man findet 
auch sehr schnell kompetente Hilfe, wie man etwas macht, z.B. unter 
stackoverflow.com.
Daß man Sonderzeichen und Leerzeichen mit "" klammern muß, ist doch ein 
alter Hut.

Ich tue mich z.B. schwer, ein Makefile zu erstellen, wird aber 
gefordert. Also habe ich mir ein amake.bat geschrieben, was makefile 
erstellt, weil ja Make keine Wildcards expandieren kann, es dann aufruft 
und danach gleich atprogram.exe zum Flashen.
Statt im makefile zu editieren, reicht also ein Doppelklick und die neue 
Firmware ist im MC.

Eine weitere Batch haben ich, um nach dem Altium Output-Job alles zu 
zippen und benennen, wie es für unser Buchungssystem benötigt wird. 
Kürzlich mußte ich eine Zeile hinzufügen für das Konvertieren von XLS 
nach XLSX.
XLS wird nicht mehr in E-Mails durchgelassen.

[c-hater (Gast)]

cppbert schrieb:

> die Bash hat solche Problem nicht

Wie bitte? Die bash kackt bei inkorrektem Quoting ganz genauso ab wie 
MS-cmd. Mehr noch: Absolut JEDE Scriptsprache hat dieses Problem!

> und das Fehlerfeedback ist auch klarer

Das kommt drauf an, wo der Quotingfehler sitzt. Manchmal ist der 
Interpreter halt in der Lage, zu erkennen, dass da was nicht passen 
kann, aber sehr oft eben auch nicht. Und das ist bei absolut JEDER 
Scriptsprache so. Das liegt in der Natur des Problems.

Das kann man übrigens kinderleicht daran erkennen, dass Quoting 
überhaupt nötig ist. Wenn man denken kann...