Hallo,
mir stellt sich folgendes Problem: Ich möchte in einer
Datei alle Zeilen löschen, die mit "muster" anfangen.
Dazwischendrin eine temporäre Datei anlegen möchte ich
/nicht/. Daß dies hier nicht geht, ist klar:
$ sed /^muster/d datei >datei
Interessant wird es bei Befehlen wie:
$ cat datei | sed /^muster/d >datei
$ sed /^muster/d datei | cat >datei
Das geht für kurze Dateien, lange werden irgendwo
mittendrin abgeschnitten.
Ich könnte mir selbst einen cat schreiben, der die Datei
mit `flock()' oder so sperrt; das bräuchte ich nicht,
wenn es für das Problem schon eine Lösung gäbe.
Wenn ja, welche?
Gruß
Bertram
--
Bertram Scharpf
Bertram Scharpf schrieb:
Hallo,
mir stellt sich folgendes Problem: Ich möchte in einer Datei alle Zeilen löschen, die mit "muster" anfangen. Dazwischendrin eine temporäre Datei anlegen möchte ich /nicht/. Daß dies hier nicht geht, ist klar:
$ sed /^muster/d datei >datei
Interessant wird es bei Befehlen wie:
$ cat datei | sed /^muster/d >datei $ sed /^muster/d datei | cat >datei
Das geht für kurze Dateien, lange werden irgendwo mittendrin abgeschnitten.
Ich könnte mir selbst einen cat schreiben, der die Datei mit `flock()' oder so sperrt; das bräuchte ich nicht, wenn es für das Problem schon eine Lösung gäbe.
Wenn ja, welche?
Hallo, warumm machst Du nicht ... datei .........>datei.new .... mv datei.new datei Gruß, Dirk
Hallo Liste!
Dirk Gerlach
Bertram Scharpf schrieb:
Interessant wird es bei Befehlen wie: $ cat datei | sed /^muster/d >datei $ sed /^muster/d datei | cat >datei
Das geht für kurze Dateien, lange werden irgendwo mittendrin abgeschnitten.
Eben - ist total unschön, da es abhängig davon ist, wie gross die Puffer sind und wann diese auf Platte geflusht werden. Also ist das Ergebnis nicht vorhersagbar. Ist somit in meinen Augen keine gute Idee!
Ich könnte mir selbst einen cat schreiben, der die Datei mit `flock()' oder so sperrt; das bräuchte ich nicht, wenn es für das Problem schon eine Lösung gäbe.
Ja - den Umweg über eine zusätzliche Datei. Dies ist IMHO schlicht die einfachste und beste Lösung.
... datei .........>datei.new mv datei.new datei
Hier ist es meiner Meinung nach Geschmacksache, wie man vorgehen will. Bei dem mv über eine existierende Datei wäre ich noch etwas vorsichtiger - ich mache da immer erst ein rm drauf. (Man weiss nie, unter welchen eigenartigen Unix Derivaten das Teil hinterher laufen wird, daher immer etwas vorsichtiger!) Eine Überlegung wäre vielleicht auch, das alles über einen Puffer laufen zu lassen. Aber da verlässt mich mein Wissen auch schon wieder. Ich habe da nur ein paar Brocken, die ich denen mit zuviel Zeit vorwerfen kann: - Named Pipes habe ich irgendwie im Kopf. - Advaced Bash-Scripting Guide des LDP (www.linuxdocs.org). Da findet sich vielleicht etwas, aber das Ergebnis ist da dann streng genommen das Gleiche! Die temporäre Datei ist dann aber halt nur im Speicher. Dies ist aber kein Geschwindigkeitsvorteil (zumindest nicht gross), da die Daten so oder so genau einmal geschrieben werden! Die Lösung mit der temporären Datei ist sogar deutlich schöner, da ich da die Datei nie richtig gesperrt habe. Wenn auf die Datei zugegriffen wird, solane ich meine Operation in die neue Datei laufen lasse, stört mich dies gar nicht. Wenn die Datei noch offen ist, wenn das rm (oder das mv) kommt, dann wird die Datei nur aus dem Verzeichnis entfernt, aber die Datei bleibt bestehen, solange die Datei nicht geschlossen wird. Die Datei ist ganz kurz nicht erreichbar! (Zeit vom rm bis zum mv!) Danach ist die Datei sofort wieder verfügbar! Gerade bei grossen Dateien, die evtl Infos enthalten, auf die regelmässig zugegriffen werden könnte und wo die Datei relativ komplett sein sollte, da ist dies angebracht. (Wenn der Job z.B. nur ein paar kleine Fehler beheben soll oder eine Erweiterung vornehmen soll, da ist es nicht akzeptabel, dass man da den Service komplett stopt. Beispiel fällt mir nicht so 100% eins ein. Kleiner Versuch: An der /etc/passwd soll etwas geändert werden - z.B. alle, die die bash1 bisher hatten sollen nun die bash kriegen. Diese Änderung kann man durchführen, nur sollte man da immer Sorge tragen, dass sich alle immer einloggen können oder dass der Ausfall extrem gering ist. Naja - doofes Beispiel, aber vielleicht ist deutlich geworden, was ich meine. Mit den besten Grüßen, Konrad Neitzel -- SoftMediaTec GmbH Tel: 0172 / 689 31 45 Fax: 069 / 90 50 99 53
participants (3)
-
Bertram Scharpf -
Dirk Gerlach -
Konrad Neitzel