Gib mal ein praktisches Beispiel vielleicht
ein Pipe wo man text reinschreibt und auf der anderen Seite wird es z.B. von gzip aufgefangen und gezippt in eine Datei geschrieben. geht das? oder muss man ein c-Programm schreiben.
ich würde das sehr gerne in perl verwenden (CGI-scripts).
/usr auf neu Platte auslagern
-
andre
Re: /usr auf neu Platte auslagern
Immer noch offtopic ... <img src="http://www.pro-linux.de/Images/Wilk.gif" border="0" align="middle">
Ok. gzip. gzip ist komisch, weil es naemlich eigentlich automatisch von stdin liest, aber nur, wenn stdin auf eine pipe umgeleitet ist. Nun willst Du aber eigentlich direkt von stdin lesen, also musst Du das von stdin mit cat in eine pipe umwandeln. cat liest also von stdin (das ist wieder der Trick mit dem Minus) und dann sorgt die shell fuer eine unbenannte pipe zwischen stdout von cat nach stdin von gzip. Und die Ausgabe von gzip leiten wir dann in eine Datei. Sprich folgendes:
cat -|gzip > test.gz
Rufe mal die Zeile auf und tippe dann mal einen kleinen Text ein und schliesse Deine Eingabe mit <ctrl>d ab (das ist das Zeichen fuer Ende des Terminals ... sehr nuetzlich, denn damit kann man z.B. auch eine shell einfach schliessen <img src="http://www.pro-linux.de/Images/Wilk.gif" border="0" align="middle">). Danach hast Du automatisch ohne Umweg eine gezipte Datei Deines Textes! Soweit Dein Problem also geloest, wenn ich es richtig verstanden hab?
In dem Fall kuemmert sich also die shell drum, die stdin/stdout-Kanaele der Programme entsprechend ueber eine Pipe zu verbinden und das Ergebnis in eine Datei umzulenken. Falls Du das natuerlich nicht auf der shell brauchst, sondern in einem Programm, kann ich Dir aber auch erklaeren, wie das da geht. Perl unterstuetzt Pipes sehr einfach und clever ueber ein Symbol am Anfang eines Dateinamens (alles weitere geht ja dann wie mit Dateien) und unter C braucht man dazu die entsprechenden C Routinen und muss es von Hand initiieren, was aber mit ein paar Handgriffen auch getan ist ...
Andre
Ok. gzip. gzip ist komisch, weil es naemlich eigentlich automatisch von stdin liest, aber nur, wenn stdin auf eine pipe umgeleitet ist. Nun willst Du aber eigentlich direkt von stdin lesen, also musst Du das von stdin mit cat in eine pipe umwandeln. cat liest also von stdin (das ist wieder der Trick mit dem Minus) und dann sorgt die shell fuer eine unbenannte pipe zwischen stdout von cat nach stdin von gzip. Und die Ausgabe von gzip leiten wir dann in eine Datei. Sprich folgendes:
cat -|gzip > test.gz
Rufe mal die Zeile auf und tippe dann mal einen kleinen Text ein und schliesse Deine Eingabe mit <ctrl>d ab (das ist das Zeichen fuer Ende des Terminals ... sehr nuetzlich, denn damit kann man z.B. auch eine shell einfach schliessen <img src="http://www.pro-linux.de/Images/Wilk.gif" border="0" align="middle">). Danach hast Du automatisch ohne Umweg eine gezipte Datei Deines Textes! Soweit Dein Problem also geloest, wenn ich es richtig verstanden hab?
In dem Fall kuemmert sich also die shell drum, die stdin/stdout-Kanaele der Programme entsprechend ueber eine Pipe zu verbinden und das Ergebnis in eine Datei umzulenken. Falls Du das natuerlich nicht auf der shell brauchst, sondern in einem Programm, kann ich Dir aber auch erklaeren, wie das da geht. Perl unterstuetzt Pipes sehr einfach und clever ueber ein Symbol am Anfang eines Dateinamens (alles weitere geht ja dann wie mit Dateien) und unter C braucht man dazu die entsprechenden C Routinen und muss es von Hand initiieren, was aber mit ein paar Handgriffen auch getan ist ...
Andre
-
jens
Re: /usr auf neu Platte auslagern
ne ich verstehe ja die standard pipes ganz gut.
nur bei named pipes gibts bei mir ein kleines denkproblem. ich lege eine named pipe an
mit mknod denke ich.
nun der wichtige Teil
in die pipe reinschreiben, kein problem, aus der pipe lesen, kein problem. nun ist ja eine pipe wie ein Tunnel zu verstehen eine Seite raus die andere Seite rein ich habe aber nur eine Seite.??:?
nur bei named pipes gibts bei mir ein kleines denkproblem. ich lege eine named pipe an
mit mknod denke ich.
nun der wichtige Teil
in die pipe reinschreiben, kein problem, aus der pipe lesen, kein problem. nun ist ja eine pipe wie ein Tunnel zu verstehen eine Seite raus die andere Seite rein ich habe aber nur eine Seite.??:?
-
hendrik
Re: /usr auf neu Platte auslagern
bleiben wie mal bei röhren, kein tunnel sondern sagen wir mal wasserleitungen die ein ventiel zwischenhängen haben.
so wie ich die named pipes verstehe kann man diese ale regelventiel ansehen.
es wird eine angelegt (mknod <name der datei>)--> sagen wir mal das regelventiel.
die aufgabe, wenn ich es richtig verstanden, habe besteht jetzt darin zwei verschiedene prozesse, vieleicht auch mehr, auszuführen. z.B einer schreibt daten hinein und ein anderer liest daten herraus, wobei die prosesse von zwei völlig verschiedenen terminals ausgelösst werden. berichtigt mich wenn ich da falsch liege!<img src="http://www.pro-linux.de/Images/Wilk.gif" border="0" align="middle">
so z.B es wird ein gerät aufgerufen so ruft ein prosess das gerät auf (dev...) ein anderer liesst die gerätedaten damit dieses auch richtig läuft und eingebunden werden kann. Ist das richtig verstanden?? also, um zum Beispiel ventiel zurück zukommen, ein Befehl sagt öffnen ein anderer liest den durchfluss/oder druck ab und steuert so wie weit es sich öffnen darf. richtig? die named pipe dient also sozusagen zum datenaustausch und muss nicht immer wieder von vorn programmiert werden sondern wartet bis sie aufgerufen bzw. angesteuert wird. So wie ich das verstanden habe wird sie einmal angelegt und kann dann von jedem genutzt werden
hendrik
so wie ich die named pipes verstehe kann man diese ale regelventiel ansehen.
es wird eine angelegt (mknod <name der datei>)--> sagen wir mal das regelventiel.
die aufgabe, wenn ich es richtig verstanden, habe besteht jetzt darin zwei verschiedene prozesse, vieleicht auch mehr, auszuführen. z.B einer schreibt daten hinein und ein anderer liest daten herraus, wobei die prosesse von zwei völlig verschiedenen terminals ausgelösst werden. berichtigt mich wenn ich da falsch liege!<img src="http://www.pro-linux.de/Images/Wilk.gif" border="0" align="middle">
so z.B es wird ein gerät aufgerufen so ruft ein prosess das gerät auf (dev...) ein anderer liesst die gerätedaten damit dieses auch richtig läuft und eingebunden werden kann. Ist das richtig verstanden?? also, um zum Beispiel ventiel zurück zukommen, ein Befehl sagt öffnen ein anderer liest den durchfluss/oder druck ab und steuert so wie weit es sich öffnen darf. richtig? die named pipe dient also sozusagen zum datenaustausch und muss nicht immer wieder von vorn programmiert werden sondern wartet bis sie aufgerufen bzw. angesteuert wird. So wie ich das verstanden habe wird sie einmal angelegt und kann dann von jedem genutzt werden
hendrik
-
andre
Re: /usr auf neu Platte auslagern
Wieder mal Thema pipes ... <img src="http://www.pro-linux.de/Images/Wilk.gif" border="0" align="middle">
Das Beispiel mit dem Regelventiel find ich nicht so optimal. Da fehlt naemlich der Speicherplatz. Ausserdem hat das mit auf und zu nicht viel zu tun. Nimm mal ein Silo als Vorstellung. Das geht uebrigens bei benannten und unbenannten Pipes voellig gleich. Den Unterschied schreib ich spaeter.
Jedenfalls: Was ist besonderes am Silo? Nun: Man kann oben reinschuetten und unten kommt es wieder raus. In der Reihenfolge, wie man es reinschuettet. Reinschuetten koennen (nur bei benannten Pipes) sogar mehrere gleichzeitig (schreiben glaub ich jetzt aus dem Stehgreif nicht, aber ich kann falsch liegen). Die Schreiboperationen in eine Pipe garanieren aber, dass die einzelne Schreibaktion nicht mit anderen vermischt wird, also Durcheinander bei gleichzeitigem Schreiben entsteht.
Und drunter kann jemand Reinfahren und das Silo leer machen. Gleichzeitig ist das Silo ein Puffer, kann die Daten also zwischenspeichern.
Und nun die Unterschiede zwischen benannter und unbenannter pipe: Bei einer unbenannten Pipe muessen die kommunizierenden Prozesse durch fork() einen gemeinsamen Vorfahren haben, der auch die Pipe selbst initialisiert. Es kann nur genau einen lesenden und einen schreibenden Prozess geben. Es gibt dann sogar signale, die den Prozessen sagen, wenn keiner mehr liest und keiner mehr schreibt -- jeweils an den anderen Prozess gesendet. Unbenannte Pipes werden in vielen Belangen automatischer verwaltet, z.B. werden sie automatisch geloescht (auch, wenn noch was drin war ... wenn die zwei Prozesse die pipe beide geschlossen haben, ist eben Schluss).
Und nun benannte pipes. Die muss man explizit mit einem Namen im Dateisystem anlegen. Prozesse koennen dann per Name zum Lesen und Schreiben drauf zugreifen. Es gibt also z.B. keine so Signale (weil die keinen Sinn machen, man kann ja spaeter einen Prozess starten, der wieder mit der Pipe arbeitet). Da die Pipe per Namen angesprochen wird, laesst sie sich ganz anders einsetzen, weil eben die Prozesse nicht miteinander verwandt sein muessen. Das Client/Server Beispiel, was ich Stueck weiter oben gepostet hab, find ich ganz passend fuer eine named pipe. Ansonsten braucht man sowas wohl eher weniger ... ging mir bisher zumindest so.
Andre
Das Beispiel mit dem Regelventiel find ich nicht so optimal. Da fehlt naemlich der Speicherplatz. Ausserdem hat das mit auf und zu nicht viel zu tun. Nimm mal ein Silo als Vorstellung. Das geht uebrigens bei benannten und unbenannten Pipes voellig gleich. Den Unterschied schreib ich spaeter.
Jedenfalls: Was ist besonderes am Silo? Nun: Man kann oben reinschuetten und unten kommt es wieder raus. In der Reihenfolge, wie man es reinschuettet. Reinschuetten koennen (nur bei benannten Pipes) sogar mehrere gleichzeitig (schreiben glaub ich jetzt aus dem Stehgreif nicht, aber ich kann falsch liegen). Die Schreiboperationen in eine Pipe garanieren aber, dass die einzelne Schreibaktion nicht mit anderen vermischt wird, also Durcheinander bei gleichzeitigem Schreiben entsteht.
Und drunter kann jemand Reinfahren und das Silo leer machen. Gleichzeitig ist das Silo ein Puffer, kann die Daten also zwischenspeichern.
Und nun die Unterschiede zwischen benannter und unbenannter pipe: Bei einer unbenannten Pipe muessen die kommunizierenden Prozesse durch fork() einen gemeinsamen Vorfahren haben, der auch die Pipe selbst initialisiert. Es kann nur genau einen lesenden und einen schreibenden Prozess geben. Es gibt dann sogar signale, die den Prozessen sagen, wenn keiner mehr liest und keiner mehr schreibt -- jeweils an den anderen Prozess gesendet. Unbenannte Pipes werden in vielen Belangen automatischer verwaltet, z.B. werden sie automatisch geloescht (auch, wenn noch was drin war ... wenn die zwei Prozesse die pipe beide geschlossen haben, ist eben Schluss).
Und nun benannte pipes. Die muss man explizit mit einem Namen im Dateisystem anlegen. Prozesse koennen dann per Name zum Lesen und Schreiben drauf zugreifen. Es gibt also z.B. keine so Signale (weil die keinen Sinn machen, man kann ja spaeter einen Prozess starten, der wieder mit der Pipe arbeitet). Da die Pipe per Namen angesprochen wird, laesst sie sich ganz anders einsetzen, weil eben die Prozesse nicht miteinander verwandt sein muessen. Das Client/Server Beispiel, was ich Stueck weiter oben gepostet hab, find ich ganz passend fuer eine named pipe. Ansonsten braucht man sowas wohl eher weniger ... ging mir bisher zumindest so.
Andre