XMP_RunCmd und Kodierung

  • Hallo alle zusammen,


    nach längerer Ritlabs-Abstinenz habe ich im Sommer testweise TheBat! 4.2.9 samt XMP 1.2 (die derzeit neueste Version) installiert.
    (Auf Gaijins Website steht zu lesen, XMP funktioniere bis TB! 3.99.29, ich hoffe, das Problem hängt nicht damit zusammen ...)


    Die schlechte Nachricht: Wenig hat sich seit damals geändert, Probleme/Bugs sind weitgehend identisch.
    Und ob die optischen Änderungen ein Update rechtfertigen, na ja.


    Nun zu meinem Problem bzgl. TB! 4.2 & XMP:


    Ich habe in TB! folgende Schnellvorlage eingerichtet:

    Code
    %_q=#%XMP_RunCmd('cscript /nologo .\external.vbs param',0,60)#%-
    %_q%-


    Der Skript-Aufruf cscript /nologo .\external.vbs param funktioniert in der DOS-Eingabeaufforderung (cmd.exe) unter XP auch tadellos und liefert mir einen mehrzeiligen Text variabler Länge, Ausgaben beinhalten Zeichen wie „ “ ’ – — ™ etc. Innerhalb von cmd.exe werden die wie gesagt alle korrekt dargestellt. Sobald ich aber per %XMP_RunCmd eine solche Ausgabe in eine neue Nachricht in TB! hole, werden diese Zeichen ersetzt:

    • „ und “ zu: "
    • ’ zu: '
    • – sowie — zu: -
    • ™ zu: T
    • […] zu: [.]

    usw.


    Jetzt könnte man – zumindest teilweise – gegensteuern und vor der Ausgabe von %_q% so etwas tun (' –› ’):

    Code
    %_q=#%XMP_StrRepl("%_q","'","’",1,1)#%-
    %_q%-


    Aber erstens ist das ziemlich aufwändig und zweitens hieße das, an Symptomen herumzudoktern anstelle die Ursache anzugehen.
    Meine Frage an Gaijin deshalb: Liegt die Ursache dafür im Makro %XMP_RunCmd oder sind Bugs in TB! daran Schuld?


    Gruß,
    Mikka



    P.S.:
    Bei der Ersetzung habe ich auch diesen Ausdruck getestet:

    Code
    %_q=#%XMP_StrRERepl("%_q","(?<=\s)\-","–",1)#%-


    Es funktionierte nicht, wahrscheinlich wegen des positiven Lookbehind (?<=\s).
    Ist eventuell PCRE-Support für ein Update vorgesehen?

  • Ganz einfach. Ich nehme an, das hat was mit dem Zeichensatz des Systems zu tun.
    Die Konsole als MS-DOS verwendet CP850, Windows XP selbst Windows 1252.


    //EDIT: Und es stellt sich die Frage, in welchen Zeichensatz das VBasicScript ausgibt.


    Ich kann es aber gerade nicht testen.

    The Bat! Pro 10.x BETA (32bit, keine nau) | Win 11 Pro x64 | GnuPG 2.3.x | XMP + Regula


    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

    Einmal editiert, zuletzt von GwenDragon ()

  • Hallo Gwen!

    Zitat

    Ganz einfach. Ich nehme an, das hat was mit dem Zeichensatz des Systems zu tun.

    Ja, eine Vermischung zweier unterschiedlicher Zeichensätze wäre möglich. Nur in welchem Schritt?
    (In einer früheren Diskussion, damals noch über %GMP_RunCmd, war übrigens ein Bug in TB! die Erklärung.)


    In diesem Fall liegt eine Textdatei (Windows-1252) zugrunde, die von dem VBS-Skript geparst und teilweise ausgegeben wird.

    Code
    F:\Test> cscript /nologo .\f.vbs quotes1
    Wer die falschen Fragen stellt, der erhält
    Antworten wie „42“ oder „Gott“.
    
    
    F:\Test>


    Sobald ich das in TB! importiere (neue Nachrichten sind standardmäßig bei mir Windows-1252), findet offenbar eine Character-Konvertierung statt:

    Code
    Wer die falschen Fragen stellt, der erhält
    Antworten wie "42" oder "Gott".


    Die Syntax von %XMP_RunCmd ist ja
    %XMP_RunCmd(Befehl, [NoConvert], [Timeout])

    Sofern der Parameter NoConvert also nicht auf 1 gesetzt wird (was bei mir der Fall ist), "behandelt" %XMP_RunCmd Ausgaben des cscript-Befehls irgendwie ehe diese in die Variable %_q geschrieben werden ...


    Übrigens, eben noch getestet, so etwas hier:

    Code
    cscript /nologo .\f.vbs quotes1 > %temp%\test.txt


    führt zu einer Datei test.txt (ANSI, Windows-1252) mit dem Inhalt:

    Code
    Wer die falschen Fragen stellt, der erh„lt
    Antworten wie "42" oder "Gott".


    Erwartungsgemäß ist diesmal auch das kleine ä verfälscht, nicht allein die Anführungszeichen „“.
    Was meinen Verdacht bestärkt, dass %XMP_RunCmd nicht korrekt arbeitet ...

  • Das ist ja das ärgerliche, dass die DOS-Box und Windows verschiedenen Zeichensätze haben.
    Wenn deine VBSript-Source auch noch intern keinen Zeichensatz festgelegt hat zur Ausgabe, wird es hakelig.
    Das ist das nervige an Kompatibilität zu Uralt-Sachen wie DOS.
    Würde durchgängig UTF-8 oder wenigstens eine einzige Kodierung (wie Linux es macht) verwendet, wäre es kein Problem.

    The Bat! Pro 10.x BETA (32bit, keine nau) | Win 11 Pro x64 | GnuPG 2.3.x | XMP + Regula


    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • Das VBScript enthält als Aufruf:

    Code
    fs.opentextfile(source, 1, false, 0)


    Also: Datei source wird read-only geöffnet (und nur falls vorhanden) als ANSI.
    (Auf Unicode, d.h. mehr als 1 Byte pro Zeichen, habe ich bewusst verzichtet, um die Dinge nicht zu verkomplizieren.)


    Dennoch glaube ich, dass es daran liegt, dass die korrekte Ausgabe per cscript von %XMP_RunCmd fehlerhaft konvertiert wird.
    Auch ans Konsolenkommando chcp 1252 hab ich schon gedacht, glaube aber nicht, dass das was bringt ...


    Update:
    Gaijin wies mich darauf hin, dass die DOS-Eingabeaufforderung in Windows bestimmte Zeichen automatisch konvertiert, etwa Anführungszeichen.
    Das ließ sich auch nicht verhindern, indem ich in einem Initialisierungsskript für die cmd.exe das Kommando chcp 1252 eintrug.
    Gaijins Tipp: Das VBScript umschreiben, dass die Ausgabe in eine Datei erfolgt, welche dann z.B. via %Put in TB! eingelesen wird.
    Werde ich austesten.

  • Der Zwischenschritt über eine Datei ist wohl das Beste.

    The Bat! Pro 10.x BETA (32bit, keine nau) | Win 11 Pro x64 | GnuPG 2.3.x | XMP + Regula


    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.