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: [..] Sollte UFILE="$(mktemp "/tmp/printsomething.$$.XXXXXX")" sein.
Wäre wohl besser...
Oder sowas. Prinzip sollte klar geworden sein ;)
trap "rm -f '$TFILE' '$UFILE'" 0 1 2 15 Hmm, guter Hinweis. Aber warum noch die PID in den Dateinamen reintun?
Gewohnheit ;) Schadet nix. Ist noch eine Stufe mehr gegen Kollisionen oder Angriffe.
Na ja... Gewohnheit lass' ich ja gelten. Da mktemp m.W. aber prüft ob eine Datei schon existiert und dann einen anderen Namen wählt ist die weitere Stufe gegen Kollisionen nutzlos. Besser wäre es den returncode von mktemp zu prüfen und Fehler zu behandeln :-)
Stimmt auffällig. TFILE="$(mktemp "/tmp/printsomething.XXXXXX")" || exit $?
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. 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 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 ;) 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 ;)
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". HTH, -dnh -- Hey, I can be a jerk to people I haven't slept with. I am that good. -- Dr. House -- 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