Hi 13.08.2008 04:03, David Haller wrote:
Hallo,
Am Die, 12 Aug 2008, Arno Lehmann schrieb:
12.08.2008 05:01, David Haller wrote:
Am Mon, 11 Aug 2008, Arno Lehmann schrieb: [..]
while true; do netcat -l -p 3120 > "${TFILE}" cp "${TFILE}" "${UFILE}" cat "${UFILE}" >> /dev/usb/lp0 & done
Auch wenn ich nicht kapiere, was das mit den 2 Tempfiles soll. Verhindern dass während des Ausgebens die Datei schon mit dem nächsten Job überschrieben wird, und gleichzeitig die Pause zwischen zwei netcats minimal halten... ich weiss ja nicht wie schnell die Druckjobs reinpurzeln. Ah ok, habe ich vermutet. Aber so dürfte das eher nicht wirklich funktionieren, denn netcat + cp und die Schleife warten nicht auf den Drucker. -v bitte... Ich hab' das ja alles selber nicht probiert, aber unter Annahme dass ein Druckjob am Stück reinkommt sehe ich kein Problem.
Unter der Annahme seh ich auch kein Problem, aber dann wiederum keinen Bedarf von 2 Tempfiles.
Hmm... jein. Deine Lösung mit cp & und sofort danach rm läuft aufs Gleiche hinaus. Dass ich da explizit zwei verschiedene Dateinamen nehme ist eben auch... Gewohnheit ;-)
Wenn die Daten aber häppchenweise eintrudeln, dann könnte es sinnvoll sein, aber dann ist die Schleife wiederum komisch, da sie ebenfalls nur häppchenweise auf den Drucker ausgibt (potentiell verschiedene Jobs)... Und auch da braucht's dann eigentlich nicht 2 Tempfiles.
Daten kommen an und gehen in die Temp-Datei. cp ist allerdings unsinn - mv muss es sein, das ist atomar. Da netcat zu dem Zeitpunkt nicht mehr läuft kann nichts die Datei anfassen. cat läuft dann im Hintergrund. Erst dabei kommt der Drucker ins Spiel, aber das ist dann für den Teil mit netcat irrelevant...
while true; do ## das soll doch hier der "Daemon" sein, odr? netcat -l -p 3120 > "$TFILE" ## beendet sich (erst), ## wenn der "Job" komplett(?) cat "$TFILE" > /dev/usb/lp0 & ## man beachte das '&' rm "$TFILE" done
Und das ist im Endeffekt das gleiche wie mein Vorschlag. Zugegeben, ein mktemp weniger, aber angesichts der zu erwartenden CPU- und I/O-Last durchs Schreiben auf USB zählt das nicht :-)
Solange das 'cat' noch liest, is die Datei noch da (obwohl sie von rm schon gelöscht wurde), sobald cat fertig ist oder ein Fehler auftritt ist die Datei automagisch weg. Und ja, AFAIK kann derweil netcat schon in die nächste Inkarnation von $TFILE schreiben ;)
*Könnte* (da bin ich absolut nicht sicher) vom Dateisystem abhängen. Alle klassischen Unix-Dateisysteme inkl. ext(2|3) funktionieren so. Bei FAT und NTFS bin ich nicht sicher. Allerdings würde wohl kein klar denkender unix/linux-Admin FAT als Dateisystem für /tmp verwenden...
Theoretisch sollte auch die direkte Umleitung funktionieren:
while true; do netcat -l -p 3120 > /dev/usb/lp0 done
praktisch könnten da Netzwerk-/USBprobleme einen Strich durch die Rechnung machen. Hab ich aber keinerlei Erfahrungen mit. Einen Test wäre es wert ;)
Dann viel Spass - Ich werd's nicht probieren, da hab' ich momentan doch etwas andere Problemchen zu lösen :-) Allerdings war, wenn meine Erinnerung mich nicht trügt, das grade nicht erfolgreich. Ich könnte mir vorstellen dass USB deutlich langsamer als Netzwerk ist und daher hier Probleme auftauchen wenn Druckjobs schnell nacheinander kommen. Alles was wir durchgespielt haben verhindert das nicht, macht es aber unwahrscheinlicher.
Kommen die Druckjobs komplett oder häppchenweise via netcat rein? Gute Frage, aber ohne das selber zu probieren wage ich keine Prognose. Allerdings wäre ich nicht überrascht wenn Windows hier in Scheiben sendet und über kurze Timeouts fatal stolpert...
Eben.
Und dann würde auch deine Version mit 2 Tempfiles Probleme machen, da jedes Locking (pro Job) fehlt, und somit ggfs. ein Häppchen von Job1 ausgegeben wird, dann ein Happen von Job2, dann noch ein Happen von Job1...
Das sauber zu programmieren ist nochmal etwas komplexer (woran erkennt man Jobanfang / Jobende?), da kann man dann fast schon CUPS und IPP nehmen... Oder lpr. Kann Windows ja beides. Wenn auch nicht "per Default".
Nur ging auch CUPS nicht... aber damit ist das Problem dann auch ad nauseam durchdekliniert - wir sind wieder am Anfang angekommen.
HTH,
Na, mir nicht, aber Ekkard hoffentlich... (er war das, glaub' ich, der das begonnen hatte). Arno
-dnh
-- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org