XP CMD Shell und echo '>'

Hallo,

[Vorgeschichte]
ich habe hundert Experimente machen müssen, um aus einem 
CMD-Script dies erzeugen zu können:

Befehl:
@echo " " | %callmyteestr%

Ausgabe:


%callmyteestr% ruft sich selbst auf:
@set callmyteestr=call %~f0 :myteestr

mit
 :myteestr
@for /f "tokens=1\* delims=]" %%A in ('find /V /N ""') do @call:echomyteestr %%B
@goto:eof
dem bekannten Konstrukt, um stdio zu parsen,

und
 :echomyteestr
@set tmpvar2=%1
@set tmpvar2=%tmpvar2:=^\>%
@echo.%tmpvar2:"=% 
@echo.%tmpvar2:"=%\>\>%mylog%
@goto:eof

[Ende Vorgeschichte]

Wie man sieht, war ich gezwungen, in echo "" und, statt 
%callmytee%, extra ein %callmyteestr% einzuführen. 
Hätte ich statt dessen einfach

@echo ^ | %callmytee%

verwendet, dann ...

Ich weiss es nicht mehr genau (hundert Experimente), mit 
allen möglichen Effekten musste ich kämpfen wie

- "|" syntaktisch nicht erlaubt
- auf der Console hat man etwas gesehen, in 
 %mylog% (@echo.%tmpvar2:"=%\>\>%mylog%) nicht (wohl wurde 
 "" als Redirektion interpretiert)
- aus "^,&,|,$PATH, ... enthält. 
[Der String könnte ja verschlüsselt sein und unterwegs 
entschlüsselt werden ...]

(Ganz schlimm, wenn ich den String aus einer Textdatei 
erhielte. Müsste ich ihn dann vorher parsen?? Oder wenn 
mir ein Programm ein "\>" herausgibt: Was passiert damit, 
wenn ich dies per | an andere Programme weiterreiche?

Meine Frage (die sicherlich schon 100000mal gestellt wurde 
und von Mickysoft simpel mit ersetze \> durch ^\> beantwortet 
wird):

Wie verpacke ich einen String (eine Ausgabe), der (die) nicht 
weiter interpretiert werden soll, weder von der Konsole noch 
von jedweglichen Filtern (wie tee)?

Wo kann ich nachlesen (und verstehen), was ich bei meinen 
hundert Experimenten vielfältig erfahren habe? (Ein wenig 
haben mir die Google-Stichworte gefehlt, da Google nicht 
alphanumerische Zeichen nicht zulässt.)

P.S. In die Problemwelt wurde ich wie folgt gestoßen:

Das Skript lief perfekt. Hätte ich

myskript.cmd \> mylog.log

verwendet, wäre ich nie auf die Idee gekommen, die Frage 
oben zu stellen.

Dann wollte ich lediglich einen Tee-Filter einbauen, um die 
Befehle und deren Ausgabe neben der Ausgabe auf der Konsole 
mit einem Timestamp versehen in eine Datei zu loggen. Das Log 
enthielt alles bis auf den Teil am Schluss, in dem



etc. von meinem Skript ausgegeben wurde ... (offensichtlich 
wurde \> am Ende der Zeile als "\>nul" interpretiert)

Gruß

Hallo,

sind wohl nicht viele Programmierer hier?

Hier eine alternative Formulierung

------------------------------------------
C:\Dokumente und ...\>echo ^\>
\>
C:\Dokumente und ...\>echo ^\> \> more \> CON
\>
C:\Dokumente und ...\>echo ^^^\> | more
\>
------------------------------------------

Hingegen ergibt:

------------------------------------------
C:\Dokumente und ...\>echo ^\> | more \> CON
Syntaxfehler.
C:\Dokumente und ...\>echo ^\> | more
Syntaxfehler.
C:\Dokumente und ...\>echo ^\> \> more

------------------------------------------

Das Verhalten kann man sicherlich wissenschaftlich erklären, wenn man gut beim Raten ist.

 "echo ^\> | more" "echo. & \>more" 

(D.h. Syntaxfehler bei „>more“ ist gerechtfertigt.)

 "echo ^\> \> more" "echo. \>\>more" 

??!!

Aber
(a) es macht für mich keinen Sinn,
(b) erfordert das Erlernen von Merkregeln, wenn man es voraussagen möchte, und
© - mein großes Anliegen - ist nicht praktikabel. Was nützt mir eine pipe (’|’), wenn ich dafür zwei Varianten von echo in der Vergangenheit bereithalten muss,

echo ^\>

und

echo ^^^\>

nämlich, in Abhängigkeit davon, ob „in der Zukunft“ das pipe Symbol auftaucht oder nicht, was u.U. nicht in der Hand des Erstellers der echo Anweisung liegt.

… Mich würde der Source Code von CMD.EXE interessieren, der für diesen Schlamassel verantwortlich ist …

Hmmm… So ganz im Griff habe ich die Sache noch nicht. Sonst wüsste ich, warum

C:\Dokumente und ...\>set "PIPE=\>.x && type .x |"

C:\Dokumente und ...\>echo ^\> %PIPE% more 

\>

so funktioniert, wie ich es von

echo ^\> | more

wünschte!

Gruß