OS2.org Forum

Es ist der Anschlusstreiber SLPR installiert, welcher an einen Druckertreiber gebunden ist.

Welche einfachste Möglichkeit gibt es, eine Binärdatei mit aufbereiteten Druck-Job an diesen Drucker zu kopieren. Batch-Betrieb ohne Interaktion wäre sinnvoll.

Wenn der Drucker am LPT1-Port angeschlossen ist, wäre ein entsprechendes Kommando

copy TEST.LP LPT1

Wie lautet dies bei Ausgabe auf SLPR1?

hneubert hat geschrieben: ↑Di 9. Okt 2018, 11:48 Es ist der Anschlusstreiber SLPR installiert, welcher an einen Druckertreiber gebunden ist.

Welche einfachste Möglichkeit gibt es, eine Binärdatei mit aufbereiteten Druck-Job an diesen Drucker zu kopieren. Batch-Betrieb ohne Interaktion wäre sinnvoll.

Wenn der Drucker am LPT1-Port angeschlossen ist, wäre ein entsprechendes Kommando

copy TEST.LP LPT1

Das geht auch für andere Anschlüsse indem man eine Anschlußumleitung (Redirection) des entsprechenden Anschlusses einrichtet.

Wie lautet dies bei Ausgabe auf SLPR1?

Wenn nur ein SLPR-Anschluß eingerichtet wurde, kann man einfach den vorgegebenen Anschlußnamen "SLPR1" verwenden.

Es sind 2 SLPR-Anschlüsse installiert: slpr1 und slpr2.

Allerdings wird bei Angabe eines dieser Namen beim copy-Befehl das Ziel nicht als Gerätename verstanden, sondern als Datei, d.h. eine Datei namens "slpr1" angelegt.

Das überrascht nicht. LPT1 ist, im Gegensatz zu SLPR1, ein reservierter Gerätename, ebenso wie COM1,COM2,COM... sowie LPT2, LPT3,LPT..., CON und NUL (ich glaube auch AUX ist als Gerätename reserviert). Der wird also von OS/2 als Gerät behandelt und nicht als Datei.

Also gilt der erste Vorschlag: SLPR1 auf LPT1 umleiten. Das geht über das SLPR1 Port-Objekt.

Wenn es dann noch immer nicht geht kann es sein dass womöglich der PRINT01.SYS aus der config.sys auskommentiert werden muss (wenn er denn geladen wird. Der ist sowieso überflüssig weil wohl niemand heute noch einen Parallelport benutzt).

Die Möglichkeit, über die graphische Benutzeroberfläche bei den Spooler-Einstellungen den Anschluss LPT1 umzuleiten auf ein anderes Druckerobjekt, welches SLPR1 als Anschluss hat, funktioniert.

Kann diese Zuordnung auch per Kommandozeile im Batchbetrieb ablaufen? Damit könnte man dann zumindest abhängig vom aktuellen Benutzer und Umgebungsvariablen eine fallweise passende Umleitung voreinstellen, ohne Benutzer-Interaktionen zu benötigen.

Die Umleitung für den Ausgabeanschluß muß nur einmal eingestellt werden. Zum Beispiel LPT3 wird umgeleitet auf den entsprechenden virtuellen SLPR-Anschluß, dann funktioniert es auch auf der DOS-Befehlszeile.

Eine Alternative im lokalen Netz wäre bei erfolgter Anmeldung die Verwendung eines Alias für die Warteschlange (\\NETZNAME\SLPR1). Bitte entschuldigt die Verwirrung in meiner vorherigen Antwort. Ich bin davon ausgegangen, daß in Druckumgebungen dank SSI meist UNC-Ziele verwendet werden. Eine Diskussion über die magischen Dateinamen (oder Gerätenamen) würde an dieser Stelle den Rahmen sprengen. Bzgl. DOS-Sitzungen stimmen die Ausführungen von Lars. Dort werden auch alle Erweiterungen dieser Namen (z.B. LPT.xyz oder CLOCK$.1) so behandelt.
In OS/2-Sitzungen sind die Namen mit Erweiterungen und auch AUX erlaubt.

Möchte man das Drucksubsystem umgehen läßt sich dies über Pipes realisieren. Siehe \PIPE\LPD0 zur PMPRINT-Integration.
Per IP hat man viele Möglichkeiten, hier genannt nur die einfachsten : Pipe mit netcat an die IP-Anschlußnummer, Hochladen der Datei per FTP oder den Befehl LPR mit den passenden Parametern ausführen.

Auch unter OS/2 sind die "LPTx", "COMx", "NUL", "CON" (,"AUX") Namen als Gerätenamen reserviert. Es ist unmöglich unter OS/2 eine Datei mit diesen Namen anzulegen. Das hat OS/2 genauso von DOS geerbt.

erdmann hat geschrieben: ↑Fr 12. Okt 2018, 12:45 Auch unter OS/2 sind die "LPTx", "COMx", "NUL", "CON" (,"AUX") Namen als Gerätenamen reserviert. Es ist unmöglich unter OS/2 eine Datei mit diesen Namen anzulegen. Das hat OS/2 genauso von DOS geerbt.

Aber dies trifft so nur für die DOS-Sitzung(en) zu. Es ist problemlos möglich Dateien (oder Verzeichnisse) mit den Namen AUX oder LPT1.123 in OS/2-Sitzungen anzulegen. Mir ist keine Quelle bekannt, welche die Erbschaftstheorie untermauern würde.

@erdmann sprach von "LPTx", nicht von "LPT1.123". Und "AUX" war sowieso unter Vorbehalt genannt. Im Übrigen lassen sich Dateien namens "LPTx" oder "COMx" auch unter OS/2 erzeugen. Aber nur, wenn man die ansonsten für diese Namen verantwortlichen Treiber (PRINT01.SYS bzw. COM.SYS) nicht lädt.