"netcat -l -p 3120" in einer while-Schleife nimmt keine Daten mehr an
Ich will von einer Suse 10.2 auf die anderen Daten per netcat schickcn: PC_Sender: im xterm (root): #cat mytext.txt | netcat 192.168.0.37 3120 PC_Emfaenger: im xterm (root): while true; do netcat -l -p 3120 >/tmp/t; done Es kommt beim Empfänger aber nichts an! Es wird lediglich eine leere Datei /tmp/t erzeugt. Die Datei bekommt auch einen aktuellen Zeitstempel, wird also tatsächlich immer wieder neu erzeugt. Lasse ich die while-Schleife weg, gebe als nur ein: PC_Emfaenger: im xterm (root): netcat -l -p 3120 >/tmp/t Dann bekommt die Datei /tmp/t korrekt den Inhalt von mytext.txt!!! Also verhindert die while-Schleife die Datenübertragung. Weiss jmd warum? Übrigens: bei Suse 8.2 gings noch mit der while-Schleife. Warum das ganze? - Es soll die Datei mytext.txt direkt auf /dev/usb/lp0 ausgegeben werden. CUPS verlangt die Programmierung eines eigenen backend spezielle für non-postscript-Dateien, das ist hohe Mathematik für mich. UriDevice /dev/usb/lp0 geht übrigens unter Suse 10.2 nicht ... siehe andere threads. Daher: mit netcat die Datei rüber und per cat auf /dev/usb/lp0 ausgeben, das geht grundsätzlich, nur eben mit while nicht :-( Gruss Ekkard -- 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
Hi, 30.07.2008 21:21, Ekkard Gerlach wrote:
Ich will von einer Suse 10.2 auf die anderen Daten per netcat schickcn:
PC_Sender: im xterm (root): #cat mytext.txt | netcat 192.168.0.37 3120
PC_Emfaenger: im xterm (root): while true; do netcat -l -p 3120 >/tmp/t; done
Schon klar... Lies' mal die Schleife etwas "expandiert"... Starte netcat mit Ausgabe nach /tmp/t wobei die Ausgabedatei *ersetzt* wird. Wenn netcat beendet ist - sprich, wenn die Datei angekommen ist - fange von vorne an. Alles klar?
Es kommt beim Empfänger aber nichts an! Es wird lediglich eine leere Datei /tmp/t erzeugt. Die Datei bekommt auch einen aktuellen Zeitstempel, wird also tatsächlich immer wieder neu erzeugt.
Lasse ich die while-Schleife weg, gebe als nur ein:
PC_Emfaenger: im xterm (root): netcat -l -p 3120 >/tmp/t
Dann bekommt die Datei /tmp/t korrekt den Inhalt von mytext.txt!!! Also verhindert die while-Schleife die Datenübertragung.
Nein.
Weiss jmd warum?
Ja.
Übrigens: bei Suse 8.2 gings noch mit der while-Schleife.
Wundert mich...
Warum das ganze? - Es soll die Datei mytext.txt direkt auf /dev/usb/lp0 ausgegeben werden. CUPS verlangt die Programmierung eines eigenen backend spezielle für non-postscript-Dateien, das ist hohe Mathematik für mich. UriDevice /dev/usb/lp0 geht übrigens unter Suse 10.2 nicht ... siehe andere threads. Daher: mit netcat die Datei rüber und per cat auf /dev/usb/lp0 ausgeben, das geht grundsätzlich, nur eben mit while nicht :-(
Das würde ich anders lösen: TFILE=`mktemp printsomethingXXXXX` while true; do netcat -l -p 3120 > ${TFILE} UFILE=`mktmp printsomethingXXX` mv ${TFILE} ${UFILE} cat ${UFILE} >> /dev/usb/lp0 && rm ${UFILE} & done Quoting, Locking und Fehlerbehandlung und beheben meiner Fehler darfst du selber machen :-) (Aber beim Quoting hilft David sicher gern ;-) Arno
Gruss Ekkard
-- 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
Ihr beide habt recht! Vielen Dank, netcat setzt die Datei im Wartezustand "listen" auf null und nicht erst beim empfangen, alles klar. Unter Suse8.2 hatte ich damals direkt ohne Umwege auf /dev/usb/lp0 geschrieben, da ist mein Gedankenfehler nicht aufgefallen, jetzt schreibe ich vorher in eine Datei und dann machts eben *PENG* ;-) Gruss Ekkard -- 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
Hallo, Am Mit, 30 Jul 2008, Arno Lehmann schrieb:
Das würde ich anders lösen:
TFILE=`mktemp printsomethingXXXXX` while true; do netcat -l -p 3120 > ${TFILE} UFILE=`mktmp printsomethingXXX` mv ${TFILE} ${UFILE} cat ${UFILE} >> /dev/usb/lp0 && rm ${UFILE} & done
Quoting, Locking und Fehlerbehandlung und beheben meiner Fehler darfst du selber machen :-) (Aber beim Quoting hilft David sicher gern ;-)
Generell: immer so "gut" wie möglich quoten. TFILE="$(mktemp "/tmp/printsomething.$$.XXXXXX")" UFILE="$(mktmp "printsomething.$$.XXXXXX")" trap "rm -f '$TFILE' '$UFILE'" 0 1 2 15 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. -dnh -- I have a great deal of fun with fundie Xtians when they quote "THE BIBLE," meaning the New Testament. I reply, "Oh, you mean the unauthorized appendix to The Bible, not The Bible itself; I'm Jewish, and that's not part of *my* Bible." -- Joe Zeff -- 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
Hi, etwas später, war im Urlaub :-) 31.07.2008 18:36, David Haller wrote:
Hallo,
Am Mit, 30 Jul 2008, Arno Lehmann schrieb:
Das würde ich anders lösen:
TFILE=`mktemp printsomethingXXXXX` while true; do netcat -l -p 3120 > ${TFILE} UFILE=`mktmp printsomethingXXX` mv ${TFILE} ${UFILE} cat ${UFILE} >> /dev/usb/lp0 && rm ${UFILE} & done
Quoting, Locking und Fehlerbehandlung und beheben meiner Fehler darfst du selber machen :-) (Aber beim Quoting hilft David sicher gern ;-)
Generell: immer so "gut" wie möglich quoten.
Danke :-)
TFILE="$(mktemp "/tmp/printsomething.$$.XXXXXX")" UFILE="$(mktmp "printsomething.$$.XXXXXX")" trap "rm -f '$TFILE' '$UFILE'" 0 1 2 15
Hmm, guter Hinweis. Aber warum noch die PID in den Dateinamen reintun?
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. 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
Hallo, Am Mon, 11 Aug 2008, Arno Lehmann schrieb:
31.07.2008 18:36, David Haller wrote:
Am Mit, 30 Jul 2008, Arno Lehmann schrieb:
Das würde ich anders lösen:
TFILE=`mktemp printsomethingXXXXX` while true; do netcat -l -p 3120 > ${TFILE} UFILE=`mktmp printsomethingXXX` mv ${TFILE} ${UFILE} cat ${UFILE} >> /dev/usb/lp0 && rm ${UFILE} & done
Quoting, Locking und Fehlerbehandlung und beheben meiner Fehler darfst du selber machen :-) (Aber beim Quoting hilft David sicher gern ;-)
Generell: immer so "gut" wie möglich quoten.
Danke :-)
TFILE="$(mktemp "/tmp/printsomething.$$.XXXXXX")" UFILE="$(mktmp "printsomething.$$.XXXXXX")"
Sollte UFILE="$(mktemp "/tmp/printsomething.$$.XXXXXX")" 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.
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. Kommen die Druckjobs komplett oder häppchenweise via netcat rein? -dnh -- Windows has detected that a gnat has farted near your computer. Press any key to reboot. [Simon Oke] -- 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
Hi, 12.08.2008 05:01, David Haller wrote:
Hallo,
Am Mon, 11 Aug 2008, Arno Lehmann schrieb:
31.07.2008 18:36, David Haller wrote:
Am Mit, 30 Jul 2008, Arno Lehmann schrieb:
Das würde ich anders lösen:
TFILE=`mktemp printsomethingXXXXX` while true; do netcat -l -p 3120 > ${TFILE} UFILE=`mktmp printsomethingXXX` mv ${TFILE} ${UFILE} cat ${UFILE} >> /dev/usb/lp0 && rm ${UFILE} & done
Quoting, Locking und Fehlerbehandlung und beheben meiner Fehler darfst du selber machen :-) (Aber beim Quoting hilft David sicher gern ;-) Generell: immer so "gut" wie möglich quoten. Danke :-)
TFILE="$(mktemp "/tmp/printsomething.$$.XXXXXX")" UFILE="$(mktmp "printsomething.$$.XXXXXX")"
Sollte UFILE="$(mktemp "/tmp/printsomething.$$.XXXXXX")" sein.
Wäre wohl besser...
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 :-)
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. 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...
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... 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
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
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
Hallo, Am Mit, 30 Jul 2008, Ekkard Gerlach schrieb:
Ich will von einer Suse 10.2 auf die anderen Daten per netcat schickcn:
PC_Sender: im xterm (root): #cat mytext.txt | netcat 192.168.0.37 3120
PC_Emfaenger: im xterm (root): while true; do netcat -l -p 3120 >/tmp/t; done ^^*PENG*
Es kommt beim Empfänger aber nichts an! Es wird lediglich eine leere Datei /tmp/t erzeugt. Die Datei bekommt auch einen aktuellen Zeitstempel, wird also tatsächlich immer wieder neu erzeugt.
Lasse ich die while-Schleife weg, gebe als nur ein:
PC_Emfaenger: im xterm (root): netcat -l -p 3120 >/tmp/t
Dann bekommt die Datei /tmp/t korrekt den Inhalt von mytext.txt!!! Also verhindert die while-Schleife die Datenübertragung. Weiss jmd warum?
Wenn du der Shell sagst, sie soll /tmp/t bei jedem Schleifendurchlauf neu erzeugen... Nimm '>>/tmp/t'. Oder zieh die Umleitung in die Datei aus der Schleife heraus: while true; do netcat -l -p 3120; done >/tmp/t Beides sollte tun. -dnh --
Wer routet so spät durch Nacht und Wind? Es ist ein Token, das sucht seinen Ring. [Maruni und °Dieter* in dag°]
-- 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
participants (3)
-
Arno Lehmann -
David Haller -
Ekkard Gerlach