Hi, irgendwie hat es bei meinem System was gerissen, aber ich werde nicht schlau draus. SuSE 7.3prof., ein HP Laserjet III, Drucksystem ist lprold. Ein lpr -Plp text.txt schreibt folgendes in's Log unter /var/spool/lpd/ljet3-a4-auto-mono-300/log: dl5mhk:/var/spool/lpd/ljet3-a4-auto-mono-300 # cat log ls: /dev/fd/0: Ist kein Verzeichnis /var/lib/apsfilter/bin/ljet3-a4-auto-mono-300: [: -eq: unary operator expected %%[ Error: invalidfileaccess; OffendingCommand: .outputpage ]%% GNU Ghostscript 6.51: Unrecoverable error, exit code 1 dl5mhk:/var/spool/lpd/ljet3-a4-auto-mono-300 # Wo könnte denn da das Problem liegen? Früher hat die Mühle ja auch gedruckt... cu, Ralf
Ralf K. Buschner schrieb am Sat, Feb 16, 2002 at 06:39:41AM +0100:
irgendwie hat es bei meinem System was gerissen, aber ich werde nicht schlau draus. SuSE 7.3prof., ein HP Laserjet III, Drucksystem ist lprold. Ein lpr -Plp text.txt
schreibt folgendes in's Log unter /var/spool/lpd/ljet3-a4-auto-mono-300/log:
dl5mhk:/var/spool/lpd/ljet3-a4-auto-mono-300 # cat log ls: /dev/fd/0: Ist kein Verzeichnis
^^Was hat das denn mit Deinem Drucker zu tun??
/var/lib/apsfilter/bin/ljet3-a4-auto-mono-300: [: -eq: unary operator expected %%[ Error: invalidfileaccess; OffendingCommand: .outputpage ]%% GNU Ghostscript 6.51: Unrecoverable error, exit code 1 dl5mhk:/var/spool/lpd/ljet3-a4-auto-mono-300 #
Wie sieht Deine /etc/printcap aus? Ich würde mal versuchen, den Drucker mit yast neu anzulegen... Da scheint in der Konfiguration etwas verdreht zu sein. Gruß, Christian -- Christian Schmidt | Germany | christian@siebenbergen.de No HTML Mails, please!!
Hi Christian, Am Samstag, 16. Februar 2002 13:05 schrieb Christian Schmidt:
ls: /dev/fd/0: Ist kein Verzeichnis
^^Was hat das denn mit Deinem Drucker zu tun??
Immerhin will die Mühle anscheinend dort zugreifen - und zwar beim Drucken.
Wie sieht Deine /etc/printcap aus?
ascii|lp1|ljet3-a4-ascii-mono-300|ljet3 a4 ascii mono 300:\ :lp=/dev/lp0:\ :sd=/var/spool/lpd/ljet3-a4-ascii-mono-300:\ :lf=/var/spool/lpd/ljet3-a4-ascii-mono-300/log:\ :af=/var/spool/lpd/ljet3-a4-ascii-mono-300/acct:\ :if=/var/lib/apsfilter/bin/ljet3-a4-ascii-mono-300:\ :la@:mx#0:\ :tr=:cl:sh:sf: # lp|lp2|ljet3-a4-auto-mono-300|ljet3 a4 auto mono 300:\ :lp=/dev/lp0:\ :sd=/var/spool/lpd/ljet3-a4-auto-mono-300:\ :lf=/var/spool/lpd/ljet3-a4-auto-mono-300/log:\ :af=/var/spool/lpd/ljet3-a4-auto-mono-300/acct:\ :if=/var/lib/apsfilter/bin/ljet3-a4-auto-mono-300:\ /etc/printcap lines 53-75/88 90%
Ich würde mal versuchen, den Drucker mit yast neu anzulegen... Da scheint in der Konfiguration etwas verdreht zu sein.
Das hatte ich bereits. Sämtliche druckrelevanten Daten, Verzeichnisse etc. wurden entfernt und mit Yast neu installiert, für den (denkbaren) Fall, daß die aufgrund einer def. Harddisk kürzlich erforderliche Kopieraktion auf die neue Platte einige Rechte nicht korrekt übertragen haben sollte...dennoch das oben angeg. Problem. cu, Ralf
Hallo, On Sat, 16 Feb 2002, Ralf K. Buschner wrote:
Am Samstag, 16. Februar 2002 13:05 schrieb Christian Schmidt:
ls: /dev/fd/0: Ist kein Verzeichnis
^^Was hat das denn mit Deinem Drucker zu tun??
/dev/fd/0 ist "stdin", d.h. die Standardeingabe, von dem der Filter die zu druckenden Daten vom lpr bekommt.
:if=/var/lib/apsfilter/bin/ljet3-a4-ascii-mono-300:\
Ich denke der Fehler liegt in dem script... -dnh -- 22: Interaktives Fernsehen Fernsteuerung mit Taste 'Bezahlen' statt 'Aus'. ('Standpay'-Taste) (nach Peter Berlich)
Hi David, Am Samstag, 16. Februar 2002 21:08 schrieb David Haller:
ls: /dev/fd/0: Ist kein Verzeichnis
/dev/fd/0 ist "stdin", d.h. die Standardeingabe, von dem der Filter die zu druckenden Daten vom lpr bekommt.
Also müßte /dev/fd/0 ein verzeichnis sein, wenn ich das richtig interpretiere. Möglich, daß das bei meiner Rettungsaktion von der defekten Platte ein wenig gelitten hat. Könntest du bitte mal auf deinem System nachschauen, wie das auszusehen hat?
:if=/var/lib/apsfilter/bin/ljet3-a4-ascii-mono-300:\
Ich denke der Fehler liegt in dem script...
Das ist gut möglich - zwar läßt das script die Daten für den Drucker 1:1 durch, wenn man es als -Praw anspricht (schließlich sind das ja nur 3 Symlinks auf ein und dasselbe Script für die 3 Queues ascii, raw und auto), aber kann schon sein, daß da irgendwo ein fetter Wurm drin ist... cu, Ralf
Hallo, On Sun, 17 Feb 2002, Ralf K. Buschner wrote:
Am Samstag, 16. Februar 2002 21:08 schrieb David Haller:
ls: /dev/fd/0: Ist kein Verzeichnis
/dev/fd/0 ist "stdin", d.h. die Standardeingabe, von dem der Filter die zu druckenden Daten vom lpr bekommt.
Also müßte /dev/fd/0 ein verzeichnis sein,
Nein!!! Selbst /dev/fd ist _kein_ (echtes) Verzeichnis, sondern ein (pseudo!) symlink auf /proc/self/fd. Wobei /proc/self wiederum ein (pseudo!) symlink auf /proc/<PID-des-terminals> ist... Letztendlich zeigt /dev/fd/0 auf das stdin des jew. Prozesses, also z.B. bei ner konsole auf /dev/tty0 oder bei nem xterm auf /dev/pts/0 (was natuerlich in beiden Faellen _kein_ Verzeichnis, sondern ein "Character device" (zeichenorientiertes Geraet) ist... Eben deshalb kam ich auf die Schlussfolgerung:
:if=/var/lib/apsfilter/bin/ljet3-a4-ascii-mono-300:\
Ich denke der Fehler liegt in dem script...
Das ist gut möglich - zwar läßt das script die Daten für den Drucker 1:1 durch, wenn man es als -Praw anspricht [..]
Tja. Da ich das script fuer den ljet3 nicht kenne (und ehrlich gesagt auch kein Lust habe das zu debuggen, sorry)... Jedenfalls, mir scheint, das ist der schuldige... d.h. apsfilter... Sorry, zumindest heut' hab ich nicht mehr die Nerven da weitergehendes zu machen -- vielleicht hat hier ja noch jemand anderes nen Drucker, der via ljet3 von apsfilter angesprochen wird... -dnh PS: du koenntest natuerlich auch apsfilter deinstallieren, die printcap saeubern, apsfilter neu und/oder aktualisiert installieren, den Drucker neu einrichten und auf den "Redmond"-Effekt hoffen... Aber dabei wuerdest du wohl nichts lernen... ;) -- [Tivoli] : The thrill one gets from getting them to work at all helps to mask the fact that it didn't do what you wanted at all -- Paraphrase from THHGTTG
Hi David, Am Sonntag, 17. Februar 2002 06:14 schrieb David Haller:
Selbst /dev/fd ist _kein_ (echtes) Verzeichnis, sondern ein (pseudo!) symlink auf /proc/self/fd. Wobei /proc/self wiederum ein (pseudo!) symlink auf /proc/<PID-des-terminals> ist...
Genau das war das Problem. Ich habe das also durch einen Link ersetzt, jetzt geht auch das apsfilter-Script wieder so, wie es soll und die Mühle druckt wie vorgesehen. Ich hatte unlängst (wie erwähnt) einen bösen Plattenschaden und hatte idiotischerweise einen Teil des Systems mit cp kopiert anstatt tar zu verwenden. Dabei hat es wohl die ganzen Symlinks ein wenig plattgemacht. Jetzt müßte ich im Grunde ein System ganz neu aufsetzen, um ggf. einen Vergleich dafür zu haben, was nun Symlinks sein müssen und was nicht. :-( Oder gibts da noch 'ne andere denkbare Lösung? Herzlichen Dank auf jeden Fall für die Hilfe! cu, Ralf
Hallo, [bitte kein CC: ich lese in der Liste mit] On Sun, 17 Feb 2002, Ralf K. Buschner wrote:
Am Sonntag, 17. Februar 2002 06:14 schrieb David Haller: Ich hatte unlängst (wie erwähnt) einen bösen Plattenschaden und hatte idiotischerweise einen Teil des Systems mit cp kopiert anstatt tar zu verwenden. Dabei hat es wohl die ganzen Symlinks ein wenig plattgemacht. Jetzt müßte ich im Grunde ein System ganz neu aufsetzen, um ggf. einen Vergleich dafür zu haben, was nun Symlinks sein müssen und was nicht. :-( Oder gibts da noch 'ne andere denkbare Lösung?
rpm --verify rpm -qavl | grep '^l' -dnh -- 178: anvögeln coitus interruptus (Dietz Proepper)
participants (3)
-
Christian Schmidt -
David Haller -
Ralf K. Buschner