ECHO. (Zeilenvorschub) funktioniert nicht

Geschrieben von Friemler (Level 2 - Administrator in Ausbildung)

Erstellt am 19.08.2010, um 22:01:58 Uhr, Permanent-ID: 149364

Dieser Beitrag wurde bisher 3006 mal aufgerufen und gilt als gelöst.

1 von 2 Mitgliedern fanden diesen Tipp hilfreich.

0 NeutralDruckenE-Mail an FreundeBeobachten

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 face-wink

.

Gruß
Friemler

Kommentar schreibenMit Zitat

Anmeldung erforderlich!

Bitte melden Sie sich erst mit Ihrem Nicknamen und Passwort an.

Diskussionsverlauf (4 Kommentare)

Thread-Ansicht

pieh-ejdsch schreibt am 22.08.2010 um 00:01:26 Uhr
- Friemler schreibt am 22.08.2010 um 02:07:13 Uhr
  - TimoBeil schreibt am 24.08.2010 um 13:44:25 Uhr
    jeb-the-batcher schreibt am 26.08.2010 um 17:47:38 Uhr

pieh-ejdsch schreibt am 22.08.2010, 00:01:26 Uhr

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

"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 oder

cd "Ordner"
cd /d"Ordner"

wechseln.

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) mit

cd %windir%\system32

in das Verzeichnis und führe von dort den PsuedoBefehl

echo.

aus - dann fasst er auch in die Grütze wenn dort eine Datei/Ornder namens

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

AntwortenMit Zitat

Anmeldung erforderlich!

Bitte melden Sie sich erst mit Ihrem Nicknamen und Passwort an.

Friemler schreibt am 22.08.2010, 02:07:13 Uhr

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

AntwortenMit Zitat

Anmeldung erforderlich!

Bitte melden Sie sich erst mit Ihrem Nicknamen und Passwort an.

TimoBeil schreibt am 24.08.2010, 13:44:25 Uhr

Moin,

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 face-wink

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ß

AntwortenMit Zitat

Anmeldung erforderlich!

Bitte melden Sie sich erst mit Ihrem Nicknamen und Passwort an.

jeb-the-batcher schreibt am 26.08.2010, 17:47:38 Uhr

Hi,

allgemein gilt (XP/Vista)

Schlagen fehl wenn eine Datei echo. oder echo[ ... existiert (Dateioperation)

echo.
echo[
echo]
echo+01.
echo. 
02.
echo[ 
03.
echo] 
04.
echo+

Die beiden gehen auch theoretisch

echo\
echo:01.
echo\ 
02.
echo:

Schlagen aber fehl wenn my.bat im aktuellen Verzeichnis liegt (Dateioperation)

echo\..\my.bat
echo:\..\my.bat01.
echo\..\my.bat 
02.
echo:\..\my.bat

Die drei sehen an sich sehr gut aus

echo/
echo,
echo;01.
echo/ 
02.
echo, 
03.
echo;

Scheitern aber bei (zeigt die Hilfe an)

echo/?
echo,/?
echo;/?01.
echo/? 
02.
echo,/? 
03.
echo;/?

Bleibt der etwas unschön wirkende echo(, scheint aber der einzige zu sein der immer klappt

echo(01.
echo(

Vielleicht findet es ja jemand hilfreich
jeb

AntwortenMit Zitat

Anmeldung erforderlich!

Bitte melden Sie sich erst mit Ihrem Nicknamen und Passwort an.

Windows	Betriebssysteme	IT-Sicherheit & Recht	Entwicklung & Scripte
Linux & Unix	Netzwerke	Hardware Support	Multimedia
Apple MacOS	Internet & Intranet	Job & Weiterbildung	Off-Topic