linux-l: gtk und xemacs

[Jens-Uwe Morawski]

Boris Reyher wrote:
> Jens-Uwe Morawski wrote:
> > >
> > Bist du dir sicher, daß in beiden Fällen (Console - X) die
> > gleiche Shell läuft?
> > 
> Yes, denn ´echo $SHELL´ sagt mir (an der Konsole) ´/bin/tcsh´.
> Wenn ich eine weitere tcsh aufrufe, dann wird ~/.cshrc gelesen.
> Das gleiche Problem hatte ich btw auch mal bei SuSE auf einem
> anderen Rechner. Naja, ist ja auch nicht lebenswichtig... 
> 
Nur mal dumm in den Raum gefragt, wie wär es denn mal 
mit einer ~/.tcshrc  ?

> Zum Thema Drucken:
> 
> Lokal drucken geht jetzt immerhin, nachdem ich meinen lokalen
> Laserjet mit printtool eingerichtet und mit checkpc die
> fehlerhaften Eigentumsverhältnisse und Rechte in /var/spool/lpd
> bereinigt habe. Ausserdem musste ich noch von Hand
> /var/spool/lpd/lp/filter ausführbar machen. 
> 
Ging mir genauso.

> Remote tut sich aber immer noch nix. Ich werde mal LPRng
> konsultieren.
Wie schon in meiner vorherigen Mail gesagt, nehme ich jetzt den
plp. Und! Es läuft!!!

> Muss ich eigentlich in printtool bei remote Druckern einen 
> input filter angeben, wenn ich einen Druckserver angebe? 
> Oder muss ich das nur, wenn ich einen Netzdrucker direkt 
> anspreche? Soweit ich weiss, findet auf dem Druckserver
> im Rechenzentrum nochmal eine Filterung statt. 
> 
Das hängt davon ab, was der angegebene remote-Drucker akzeptiert.
Meiner hier zuhause leitet nur den Job an den Drucker weiter,
ich will nicht auf einem 486 mit 8MB ps nach PCL5 verwandeln.
Deshalb wird die Datei noch vor der Übergabe an den Remote-lpd
gefiltert, heißt bei mir nach PCL5 (ljet4) verwandelt.

Problem dabei ist, daß der lokale lpd, wenn er nach
traditioneller BSD lpd Manier arbeitet, Filtereinträge ignoriert
wenn es sich um einen Remote-Printer handelt.

Eine Lösung dafür ist apsfilter. Der arbeitet als Filter für
einen lokalen Drucker, leitet den Job aber an einen noch
konfigurierten remote-Drucker weiter. So funktioniert es bei
SuSE.
Problem: auf einem schnellen System ist der Job schnell
von der lokalen Warteschlange in die remote-warteschlange
gegangen.
Bedeutet: löschen des Jobs nicht mehr möglich, da nicht mehr
vorhanden(lokale queue) und nicht möglich weil keine
entsprechenden Rechte (remote queue), da apsfilter als User lpd
oder daemon läuft.
Außerdem ist nicht zu verstehen, wieso ein Benutzer mit
lpr <Datei>
einen Job auf den default-Printer (meist lp) mit einer Jobnummer
auslöst, und dann zum Löschen mit
lprm -P<remote-queue> <remote-queue-job-nummer-anders-als-lokal>
agieren muß. Wie soll man das jemanden beibringen???

Dieses Problem umgehen, inkl. anderen Features, plp und LPRng.
Also eine printcap mit Filter wie bei mir:

##PRINTTOOL3## REMOTE ljet4 600x600 a4 {} LaserJet4 Default {}
lp:\
	:sd=/var/spool/lpd/lp:\
	:mx#0:\
	:sh:\
	:rm=caramba.zuhause:\
	:rp=raw:\
	:if=/var/spool/lpd/lp/filter:

funktioniert mit plp auch für remote-Printer.

Jens.