Hallo, in einer *.bat Datei wäre mein COM-Port einzutragen. In der *.bat Datei finde ich:
1 | setlocal
|
2 | set comport=\\.\\com1 |
COM1 wäre korrekt, muss das
1 | \\.\\ |
so stehen bleiben? Habe ich so noch nie gesehen. Wobei DOS vor meiner Zeit war. Dietmar
|
Forum: PC Hard- und Software DOS-Befehl so korrekt?Hallo, in einer *.bat Datei wäre mein COM-Port einzutragen. In der *.bat Datei finde ich:
COM1 wäre korrekt, muss das
so stehen bleiben? Habe ich so noch nie gesehen. Wobei DOS vor meiner Zeit war. Dietmar Dietmar W. schrieb: > Habe ich so noch nie gesehen. Diese Schreibweise wird auch nur bei 2stelligen COM-Port-Nummern (die man insbesondere bei USB-Seriell-Adaptern gerne hat) zwingend benötigt. Dietmar W. schrieb: > so stehen bleiben? Glaube nich, norm. sehe ich da nur \\.\xyz123 Hier kannst ja mal nachlesen, was es damit auf sich hat: https://docs.microsoft.com/de-de/dotnet/standard/io/file-path-formats Ein gutes altes DOS kann mit \\.\\ ueberhaupt nichts anfangen. Selbst bei einem W98-DOS haette ich da Zweifel. Da du aber nur eine Environmentvariable setzt, entscheidet letztendlich die Applikation, ob sie damit etwas anfangen kann. Fuer USB-Seriell-Adapter aendere ich eher die Einstellung der Portnummber im Treiber als das ich mit so etwas anfangen wuerde. oerks schrieb: > Ein gutes altes DOS kann mit \\.\\ ueberhaupt nichts anfangen. \\ ist nichts anderes als eine Escape Sequenz für \, wie man sie auch in C Code nutzen kann und ich denke, das wird es sein. Ein String geeignet für ein Programm das in C geschrieben wurde. \\.\\ macht also \.\ Dein Befehl ist nicht richtig. DA siehst du wie das richtig geht ->>> https://www.computerhope.com/modehlp.htm Da siehst du wie das richtig geht. Einfach gesagt der COM-Port muss IMMER Initialisiert werden, mit den richtigen Parametern. Ansonsten läuft da gar nix. Nano schrieb: > \\ ist nichts anderes als eine Escape Sequenz für \, wie man sie auch in > C Code nutzen kann und ich denke, das wird es sein. Nein, die "escapelose" Schreibweise ist tatsächlich \\.\COMxx - der zusätzliche Backslash hinten ist entweder ein Tippfehler, oder Windows toleriert das. https://support.microsoft.com/en-us/topic/howto-specify-serial-ports-larger-than-com9-db9078a5-b7b6-bf00-240f-f749ebfd913e Schlaumaier schrieb: > Da siehst du wie das richtig geht. Einfach gesagt der COM-Port muss > IMMER Initialisiert werden, mit den richtigen Parametern. Ansonsten > läuft da gar nix. Typischer Schlaumaier/Alexander/Pucki-Blödsinn. Mit SET setzt er eine Environment-Variable für die danach gestartete Anwendung. Die wird sich dann schon selbst um die Initialisierung kümmern. > Ein String geeignet für ein Programm das in C geschrieben wurde.
C ist das '\' voellig egal. Es gibt da an der Stelle kein Escape.
Genau wie Java, das den selben Mechanismus nutzt.
Interpretiert wird das erst vom Betriebssystem. Hmmm schrieb: > Nein, die "escapelose" Schreibweise ist tatsächlich \\.\COMxx - der > zusätzliche Backslash hinten ist entweder ein Tippfehler, oder Windows > toleriert das. Würde ich auch so sehen. > Mit SET setzt er eine Environment-Variable für die danach gestartete > Anwendung. Die wird sich dann schon selbst um die Initialisierung > kümmern. So sieht's aus und so sah es praktisch schon immer aus, selbst unter DOS. Eigentlich hat nur die Shell selber die "default"-Einstellung benutzt, nahezu alle Anwendungen haben immer ihr eigenes Ding gemacht. Bei DOS lag das vor allem daran, das es eigentlich wiederum nur auf die vom BIOS gelieferten Routinen aufgesetzt hat, die schlicht unglaublich grottig waren und die Fähigkeiten selbst des ursprünglich verwendeten 8250 nicht wirklich ausgenutzt haben, geschweige denn die seiner Nachfolger... Hmmm schrieb: > Mit SET setzt er eine Environment-Variable für die danach gestartete > Anwendung. Die wird sich dann schon selbst um die Initialisierung > kümmern. Wenn das Programm so schlau ist, wieso macht es dann nicht alles selbst. Dos-Commands macht man nur wenn es nicht anders geht. c-hater schrieb: > Eigentlich hat nur die Shell selber die "default"-Einstellung > benutzt, nahezu alle Anwendungen haben immer ihr eigenes Ding gemacht. Völlig richtig. Und wenn die schon ihr eigenes Ding machen, dann brauchen die auch keine Shell-Befehle. Schlaumaier schrieb: > Wenn das Programm so schlau ist, wieso macht es dann nicht alles selbst. Tut es doch. Es bekommt lediglich - in diesem Fall per Environment - mitgeteilt, welchen COM-Port es verwenden soll. Schlaumaier schrieb: > Dos-Commands macht man nur wenn es nicht anders geht. Environment-Variablen sind ausserhalb Deiner beschränkten Welt nichts Ungewöhnliches. Schlaumaier schrieb: > Und wenn die schon ihr eigenes Ding machen, dann brauchen die auch keine > Shell-Befehle. Aber eine Konfiguration. Ob man die in der Registry, einer Konfigurationsdatei oder auch im Environment ablegt, ist ziemlich egal. Hmmm schrieb: > Aber eine Konfiguration. Ob man die in der Registry, einer > Konfigurationsdatei oder auch im Environment ablegt, ist ziemlich egal. Jepp. Aber genau DIE Konfiguration macht man im Programm. Da kann ich mich noch an meine GW-Basic + Powerbasic Zeit erinnern. Da habe ich öfters mit den Serial-Port gearbeitet. Und die GANZEN Einstellungen wurden im Programm gemacht. Wieso zu Hölle soll das in der modernen Zeit anders sein. Aktuell meine COM-Port-Einstellungen für die Arduino-Ansteuerung speichere + Steuere ich doch auch in meine Programm. tz tz tz Das einzige wozu ich mal den das Dos-Zeug für Serial gebraucht habe war als ich lpt1: auf com1: umgelegt habe. Was dazu führe das die Druckerausgabe meine DOS-Programm auf den Terminal-Programm meines Amiga erfolgte. Papier war teuer und Nadeldrucker laut (besonders nachts). Noch schön brav mich ESC-Code als Steuerbefehle. ;) Das waren noch Zeiten. In modernen Umgebungen habe ich das nur einmal benutzt. Um LPT1: auf USB um zu lenken. Das doofe Prg. kannte nur LPT1: als Druckerport. Schlaumaier schrieb: > Aber genau DIE Konfiguration macht man im Programm. Du als Profi weisst natürlich, wie "man" es richtig macht. Und woher weisst Du, ob dieses Programm überhaupt eine Benutzeroberfläche hat und nicht bloss ein Tool für die Commandline ist? Genau, Du weisst es nicht und lieferst deshalb nur nutzlose "Informationen" wie den obigen Unsinn bzgl. MODE. Hmmm schrieb: > Und woher weisst Du, ob dieses Programm überhaupt eine > Benutzeroberfläche hat und nicht bloss ein Tool für die Commandline ist? bei einen Tool für die Commandline übergebe ich diese Infos als Parameter. ;) Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.
|
|