5
ECHO. (Zeilenvorschub) funktioniert nicht
Der Titel des Tipps mag für alte Batch-Hasen seltsam erscheinen, aber lest erst mal weiter.
Ich habe mich heute wieder mal ins Batch-Skripting gestürzt und dabei einen lustigen Effekt entdeckt.
Ich entwickelte unter Windows 7 ein Batch-Skript, das ich auf dem Desktop abgespeichert hatte. Editor- und Browserfenster waren auf dem Hauptbildschirm geöffnet, ein CMD-Fenster und die Skriptdatei lagen auf dem Zweitmonitor auf dem Desktop. Da das Skript Parameter brauchte, wechselte ich im CMD-Fenster ins Verzeichnis %USERPROFILE%\Desktop und startete das Skript von dort.
Irgendwann baute ich einen ECHO.-Befehl ins Skript ein (Zeilenvorschub auf dem Bildschirm erzeugen). Bei Start des Skripts erschien die Fehlermeldung "Der Befehl "echo." ist entweder falsch geschrieben oder konnte nicht gefunden werden." Nanu? Seltsam war auch, das ECHO; noch funktionierte.
Ich stellte fest, daß das Skript nur fehlerfrei lief, wenn ich es in ein anderes Verzeichnis kopierte. Häh?
Des Rätsels Lösung war ebenso trivial wie verwirrend: Bei irgendeinem vorhergehenden Lauf des Skripts hatte ich wohl einen dicken Fehler im Code und auf dem Desktop (verdeckt durch Editor- und Browserfenster auf dem Hauptbildschirm) lagen Dateien mit Namen wie echo, dir, setlocal, usw. Als ich die Datei echo löschte, funktionierte mein Skript auch wieder ohne Fehlermeldung!
Soweit ich weiß, durchsucht der Befehlsinterpreter vor Ausführung eines Kommandos zuerst seine Liste der internen Befehle (dir, echo, set, usw.), dann das aktuelle Verzeichnis und dann die Verzeichnisse aus der PATH-Variablen. Hat er dann das Kommando noch nicht gefunden, gibt es obige Fehlermeldung. Bei ECHO. ist das anscheinend anders.
Übrigens: Eine Datei mit Namen ECHO z.B. ins System32-Verzeichnis (Bestandteil der PATH-Variablen) zu kopieren, führt nicht zu dem geschilderten Effekt. Sie muss im aktuellen Verzeichnis liegen. Das Batch-Skript kann aber auch in einem anderen Verzeichnis liegen und mit seinem vollständigen Pfad gestartet werden. Einen Kollegen beim Batch-Skripten zur Verzweiflung treiben ist also nicht drin
.
Gruß
Friemler
Ich habe mich heute wieder mal ins Batch-Skripting gestürzt und dabei einen lustigen Effekt entdeckt.
Ich entwickelte unter Windows 7 ein Batch-Skript, das ich auf dem Desktop abgespeichert hatte. Editor- und Browserfenster waren auf dem Hauptbildschirm geöffnet, ein CMD-Fenster und die Skriptdatei lagen auf dem Zweitmonitor auf dem Desktop. Da das Skript Parameter brauchte, wechselte ich im CMD-Fenster ins Verzeichnis %USERPROFILE%\Desktop und startete das Skript von dort.
Irgendwann baute ich einen ECHO.-Befehl ins Skript ein (Zeilenvorschub auf dem Bildschirm erzeugen). Bei Start des Skripts erschien die Fehlermeldung "Der Befehl "echo." ist entweder falsch geschrieben oder konnte nicht gefunden werden." Nanu? Seltsam war auch, das ECHO; noch funktionierte.
Ich stellte fest, daß das Skript nur fehlerfrei lief, wenn ich es in ein anderes Verzeichnis kopierte. Häh?
Des Rätsels Lösung war ebenso trivial wie verwirrend: Bei irgendeinem vorhergehenden Lauf des Skripts hatte ich wohl einen dicken Fehler im Code und auf dem Desktop (verdeckt durch Editor- und Browserfenster auf dem Hauptbildschirm) lagen Dateien mit Namen wie echo, dir, setlocal, usw. Als ich die Datei echo löschte, funktionierte mein Skript auch wieder ohne Fehlermeldung!
Soweit ich weiß, durchsucht der Befehlsinterpreter vor Ausführung eines Kommandos zuerst seine Liste der internen Befehle (dir, echo, set, usw.), dann das aktuelle Verzeichnis und dann die Verzeichnisse aus der PATH-Variablen. Hat er dann das Kommando noch nicht gefunden, gibt es obige Fehlermeldung. Bei ECHO. ist das anscheinend anders.
Übrigens: Eine Datei mit Namen ECHO z.B. ins System32-Verzeichnis (Bestandteil der PATH-Variablen) zu kopieren, führt nicht zu dem geschilderten Effekt. Sie muss im aktuellen Verzeichnis liegen. Das Batch-Skript kann aber auch in einem anderen Verzeichnis liegen und mit seinem vollständigen Pfad gestartet werden. Einen Kollegen beim Batch-Skripten zur Verzweiflung treiben ist also nicht drin
.Gruß
Friemler
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: 149364
Url: https://administrator.de/contentid/149364
Ausgedruckt am: 08.11.2024 um 15:11 Uhr
5 Kommentare
Neuester Kommentar
Hi Friemler,
Standartmässige Befehle lauten ja auch nicht echo. oder XYZ oder set.
das liegt dann wohl daran, dass zuerst in der aktuellen Umgebung (wobei ja auch der Aktuelle Pfad zu der aktuellen Umgebung zählt) durchsucht wird und wenn eine Datei oder ein Ordner mit gleichen Namen in dieser Umgebung
( =Umgebungsvariable %CD% ) Vorhanden ist wird diese Datei, wenn sie eine Extension hat, versucht mit dem Standartprogramm zu öffnen.
Gibt es Kein Programm, welches die Datei mit der Passenden Extension Öffnen kann - kommt eine Meldung
Ist ein Programm für die Datei-Endung zum standartmäsigen Öffnen Registriert wird die Datei mit diesem Programm geöffnet oder versucht zu öffnen.
Wenn die Datei Keinen . (Punkt) oder als letztes Zeichen einen Punkt hat, dann kommt es zu dieser Meldung:
Ein Ordner kann man in der CMD nur mit
In dem Sinne Braucht Dein Batch nur in ein Verzeichnis zu wechseln wo eine Datei/Ornder den selben Namen des Falschgeschriebenen Befehls hat ("ECHO." gibts ja auch als Solchen Befehl nicht - es wird ja nur der Punkt als Platzhalter verwendet) und schon fasst dieser in die Grütze.
in das Verzeichnis und führe von dort den PsuedoBefehl
aus - dann fasst er auch in die Grütze wenn dort eine Datei/Ornder namens
oder als eine Zeile zur kompletten Übersetzung geht es auch so
vllt mal mit anderen Platzhaltern wie \ / : probieren...
Gruß Phil
Standartmässige Befehle lauten ja auch nicht echo. oder XYZ oder set.
das liegt dann wohl daran, dass zuerst in der aktuellen Umgebung (wobei ja auch der Aktuelle Pfad zu der aktuellen Umgebung zählt) durchsucht wird und wenn eine Datei oder ein Ordner mit gleichen Namen in dieser Umgebung
( =Umgebungsvariable %CD% ) Vorhanden ist wird diese Datei, wenn sie eine Extension hat, versucht mit dem Standartprogramm zu öffnen.
Gibt es Kein Programm, welches die Datei mit der Passenden Extension Öffnen kann - kommt eine Meldung
"Die folgende Datei kann nicht geöffent werden"
Ist ein Programm für die Datei-Endung zum standartmäsigen Öffnen Registriert wird die Datei mit diesem Programm geöffnet oder versucht zu öffnen.
Wenn die Datei Keinen . (Punkt) oder als letztes Zeichen einen Punkt hat, dann kommt es zu dieser Meldung:
"Der Befehl "XYZ" ist entweder falsch geschrieben oder konnte nicht gefunden werden"
Ein Ordner kann man in der CMD nur mit
explorer "Ordner"
anzeigen odercd "Ordner"
cd /d"Ordner"
wechseln.cd /d"Ordner"
In dem Sinne Braucht Dein Batch nur in ein Verzeichnis zu wechseln wo eine Datei/Ornder den selben Namen des Falschgeschriebenen Befehls hat ("ECHO." gibts ja auch als Solchen Befehl nicht - es wird ja nur der Punkt als Platzhalter verwendet) und schon fasst dieser in die Grütze.
Übrigens:.... Sie muss im aktuellen Verzeichnis liegen....
wechsle (reicht auch im Batch) mitcd %windir%\system32echo.echo.
vorhanden ist.oder als eine Zeile zur kompletten Übersetzung geht es auch so
%windir%\system32\echo.vllt mal mit anderen Platzhaltern wie \ / : probieren...
Gruß Phil
Hallo Phil,
was ich seltsam finde ist, das der Befehlsinterpreter bei einem ECHO. (zur Erzeugung eines Zeilenvorschubs) überhaupt anfängt, im aktuellen Verzeichnis nach einer Datei zu suchen. Wenn es dort keine Datei echo (ohne Punkt) gibt, erkennt er dann doch, was man eigentlich vor hat (den Zeilenvorschub erzeugen) und durchsucht nicht mehr die Verzeichnisse aus der PATH-Variablen.
Wenn man eine Datei dir.exe im aktuellen Verzeichnis anlegt, kommt der Befehlsinterpreter ja auch nicht auf die Idee, bei Eingabe von DIR diese Datei auszuführen, dazu kann man ihn nur durch Eingabe von DIR.EXE zwingen.
Im Nachhinein habe ich noch festgestellt, daß, wenn ich eine Datei echo.exe, echo.com, echo.bat oder echo.cmd im aktuellen Verzeichnis anlege, ECHO. ganz normal funktioniert. Der Fehler tritt wirklich nur bei einer Datei namens echo auf.
Die Möglichkeit, mit ECHO. oder ECHO; einen Zeilenvorschub zu erzeugen, gibt es ja schon seit DOS. Wenn ich einen Kommando-Parser programmieren würde, würde ich diese Sonderformen des ECHO-Befehls in die Menge der bekannten Befehle integrieren und nicht einen Code schreiben, der zuerst den Datenträger nach einer Datei namens echo durchsucht, auf echo.exe, echo.com, echo.bat und echo.cmd aber nicht anspringt und dann auch noch die irreführende Meldung anzeigt, der Befehl könne nicht gefunden werden oder sei falsch geschrieben.
Eine Datei mit Namen echo. (mit Punkt) anzulegen, war mir übrigens bei Tests weder mit dem Explorer (Rechtsklick auf den Desktop->Neu->Textdokument, als Name echo. eintippen) noch mit der Konsole (copy con echo.) möglich. Folgt nach dem Punkt nichts, wird er einfach abgeschnitten (ist ja auch durchaus sinnvoll).
Das man das aktuelle Verzeichnis mit einem CD-Befehl ändert ist ja klar. Also wird der Befehlsinterpreter bei seiner Suche nach ausführbaren Dateien auch in dem neuen Verzeichnis suchen.
Gruß
Friemler
was ich seltsam finde ist, das der Befehlsinterpreter bei einem ECHO. (zur Erzeugung eines Zeilenvorschubs) überhaupt anfängt, im aktuellen Verzeichnis nach einer Datei zu suchen. Wenn es dort keine Datei echo (ohne Punkt) gibt, erkennt er dann doch, was man eigentlich vor hat (den Zeilenvorschub erzeugen) und durchsucht nicht mehr die Verzeichnisse aus der PATH-Variablen.
Wenn man eine Datei dir.exe im aktuellen Verzeichnis anlegt, kommt der Befehlsinterpreter ja auch nicht auf die Idee, bei Eingabe von DIR diese Datei auszuführen, dazu kann man ihn nur durch Eingabe von DIR.EXE zwingen.
Im Nachhinein habe ich noch festgestellt, daß, wenn ich eine Datei echo.exe, echo.com, echo.bat oder echo.cmd im aktuellen Verzeichnis anlege, ECHO. ganz normal funktioniert. Der Fehler tritt wirklich nur bei einer Datei namens echo auf.
Die Möglichkeit, mit ECHO. oder ECHO; einen Zeilenvorschub zu erzeugen, gibt es ja schon seit DOS. Wenn ich einen Kommando-Parser programmieren würde, würde ich diese Sonderformen des ECHO-Befehls in die Menge der bekannten Befehle integrieren und nicht einen Code schreiben, der zuerst den Datenträger nach einer Datei namens echo durchsucht, auf echo.exe, echo.com, echo.bat und echo.cmd aber nicht anspringt und dann auch noch die irreführende Meldung anzeigt, der Befehl könne nicht gefunden werden oder sei falsch geschrieben.
Eine Datei mit Namen echo. (mit Punkt) anzulegen, war mir übrigens bei Tests weder mit dem Explorer (Rechtsklick auf den Desktop->Neu->Textdokument, als Name echo. eintippen) noch mit der Konsole (copy con echo.) möglich. Folgt nach dem Punkt nichts, wird er einfach abgeschnitten (ist ja auch durchaus sinnvoll).
Das man das aktuelle Verzeichnis mit einem CD-Befehl ändert ist ja klar. Also wird der Befehlsinterpreter bei seiner Suche nach ausführbaren Dateien auch in dem neuen Verzeichnis suchen.
Gruß
Friemler
Moin,
denn dir. ist das gleiche - wie echo. und bringt auch das gleiche Ergebnis.
Das man beim "klickibunti" immer ein vorher.nachher (prefix.suffix) eingeben muß - das ist auch älter und sinnvoll
btw: der rechtklickibunti neue datei ist eh sehr speziell - versuch mal eine neue leere "irgendwas ausser txt" Datei anzulegen und benamse die dann gleich in .txt um.....
Bei einer wav Datei siehst du dann folgenden Inhalt in Notepad:
Man muß also immer wissen, was man eigentlich will und wenn man genau das macht - passiert auch das, was man haben möchte ;.-)
Gruß
Wenn man eine Datei dir.exe im aktuellen Verzeichnis anlegt, kommt der Befehlsinterpreter ja auch nicht auf die Idee
Ja - aber wenn du vorher eine Datei echo. angelegt hast, ist der Vergleich mit dir.exe etwas daneben.denn dir. ist das gleiche - wie echo. und bringt auch das gleiche Ergebnis.
Das man beim "klickibunti" immer ein vorher.nachher (prefix.suffix) eingeben muß - das ist auch älter und sinnvoll
btw: der rechtklickibunti neue datei ist eh sehr speziell - versuch mal eine neue leere "irgendwas ausser txt" Datei anzulegen und benamse die dann gleich in .txt um.....
Bei einer wav Datei siehst du dann folgenden Inhalt in Notepad:
RIFF2 WAVEfmt "V "V ( fact data
Man muß also immer wissen, was man eigentlich will und wenn man genau das macht - passiert auch das, was man haben möchte ;.-)
Gruß
Hi,
allgemein gilt (XP/Vista)
Schlagen fehl wenn eine Datei echo. oder echo[ ... existiert (Dateioperation)
Die beiden gehen auch theoretisch
Schlagen aber fehl wenn my.bat im aktuellen Verzeichnis liegt (Dateioperation)
Die drei sehen an sich sehr gut aus
Scheitern aber bei (zeigt die Hilfe an)
Bleibt der etwas unschön wirkende echo(, scheint aber der einzige zu sein der immer klappt
Vielleicht findet es ja jemand hilfreich
jeb
allgemein gilt (XP/Vista)
Schlagen fehl wenn eine Datei echo. oder echo[ ... existiert (Dateioperation)
echo.
echo[
echo]
echo+Die beiden gehen auch theoretisch
echo\
echo:Schlagen aber fehl wenn my.bat im aktuellen Verzeichnis liegt (Dateioperation)
echo\..\my.bat
echo:\..\my.batDie drei sehen an sich sehr gut aus
echo/
echo,
echo;Scheitern aber bei (zeigt die Hilfe an)
echo/?
echo,/?
echo;/?Bleibt der etwas unschön wirkende echo(, scheint aber der einzige zu sein der immer klappt
echo(Vielleicht findet es ja jemand hilfreich
jeb
Den Spaß hatte ich auch, mit
und hab erstmal gerätselt bis ich den Thread hier gefunden hab...
type xxx.yyy > echo.
