Binär-Datei Drucken an SLPR

(DE) System, Installation, Konfiguration, Hardware, Treiber, Netzwerk, Virtualisierung, etc.
(EN) System, Installation, Configuration, Hardware, Drivers, Network, Virtualisation, etc.
Antworten
hneubert
Beiträge: 57
Registriert: Mo 24. Aug 2015, 15:04

Binär-Datei Drucken an SLPR

Beitrag von hneubert »

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?
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

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.
hneubert
Beiträge: 57
Registriert: Mo 24. Aug 2015, 15:04

Beitrag von hneubert »

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.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

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).
hneubert
Beiträge: 57
Registriert: Mo 24. Aug 2015, 15:04

Beitrag von hneubert »

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.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

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.
erdmann
Beiträge: 594
Registriert: Mo 4. Jan 2016, 14:36

Beitrag von erdmann »

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.
Benutzeravatar
ak120
Beiträge: 1044
Registriert: Do 8. Mai 2014, 12:50
Wohnort: Demmin
Kontaktdaten:

Beitrag von ak120 »

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.
ehemaliger
Beiträge: 102
Registriert: Mi 22. Nov 2017, 23:46

Beitrag von ehemaliger »

@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.
Antworten