Diskussion:Sed (Unix)

message: Ich habe den Artikel etwas überarbeitet, weil er überhaupt nicht auf die Stream-Arbeitsweise des Programms eingegangen ist bzw. diese auch noch falsch erklärt hat. Dabei ist mir aufgefallen, dass recht viele Beispiele vorkommen. Ich finde das für ein Kommandozeilentool etwas viel, schließlich ist Wikipedia keine manpage. Ich höre mir aber gern andere Meinungen dazu an; ansonsten würd ich das in absehbarer Zeit mal etwas kürzen. Grüße -- Flo12 22:52, 3. Sep 2006 (CEST)
replies: text: Die Anzahl der Beispiele ist noch erträglich. sed ist schon recht kompliziert. Allerdings muss man piping nicht erläutern. Dafür gibt es schon einen Artikel. --Walter Koch 22:26, 4. Sep 2006 (CEST)
replies: text: OK, hab ich wieder rausgenommen. Gruß --Flo12 22:41, 4. Sep 2006 (CEST)
thread_title:  Zu viele Beispiele? 

message: Wie sieht es denn mit der Unterstützung für UTF-8 aus? Ich habe das Gefühl sed funktioniert überhaupt nicht bei UTF-8-zeichen. - ? --Itu 23:52, 5. Jul. 2009 (CEST)
thread_title: UTF-8 ? 

message: In dem Artikel steht nicht drin, welche konkrete RegEx Engine von sed eingesetzt wird. Da sich die Engines von ihrer Syntax her schon deutlich unterscheiden können (siehe z.B. http://www.regular-expressions.info/refflavors.html), wäre das vielleicht eine Erwähnung wert? Auf der verlinkten Seite steht auch, was bei sed unter UNIX und LINUX verwendet wird: "The sed UNIX tool uses POSIX BRE. Linux usually ships with the GNU implementation, which use 'GNU BRE'."
-- Tecturon 11:34, 18. Mai 2010 (CEST)
thread_title:  RegEx Syntax? 

message: Mehrere durchaus gravierende Fehler haben sich in den Artikel eingeschlichen:
1.) "sed -i"
Das ist KEINE sed-option und auch - richtigerweise - nicht im POSIX-Standard vorgesehen. "-i" versteht lediglich die GNU-Variante von sed und es handelt sich hierbei um eine Erweiterung des Standards, nebenbei gesagt, um eine ziemlich fragwürdige. Ich habe mal in einem UNIX-Forum einen Artikel geschrieben, warum das fragwürdig ist: . Zumindest aber sollte man erwähnen, daß das eine Erweiterung ist.
2.) "sed hat keine Variablen"
Natürlich hat sed Variablen: Zum einen den "Hold Space", in dem beliebige Teile des Eingangstexts oder auch Ergebnisse von Regexps abgelegt werden können. Weiters gibt es die Möglichkeit, Teile des Eingangstexts in Variablen zusammenzufassen und den Inhalt dieser Variablen im Ausgangstext zu verwenden:
 sed 's/^\([^ ][^ ]*\) \([^ ][^ ]*\)/\2 \1/' /path/to/input > path/to/output
vertauscht etwa die ersten beiden Worte (durch Leerzeichen begrenzte Zeichenketten) in jeder Zeile. Dabei werden im Eingangsteil durch "\(...\)" die nicht-Blanks zusammengefaßt und im Ersetzungsteil der solcherart bezeichnete Text durch "\n" repräsentiert. Genau dies ist aber die Definition einer Variablen: die Repräsentation eines Werts durch einen symbolischen Namen.
--bakunin (Diskussion) 14:50, 1. Mär. 2013 (CET)
thread_title:  Sachliche Fehler im Artikel 

message: Da niemand was dagegen einzuwenden gehabt hat, habe ich dem Lemma eine Komplettüberarbeitung angedeihen lassen. Auf die sachlichen Fehler bzw. erwähnten Auslassungen bin ich eingegangen, allerdings habe ich noch mehr (und, wie ich hoffe, bessere) Beispiele eingebaut. Mag sein, daß das keine Manpage ist, aber die Materie ist für den Nicht-Eingeweihten schon reichlich unanschaulich und ich hoffe, das behoben zu haben ohne dabei den sachlichen Anspruch aufgegeben zu haben.
--bakunin (Diskussion) 13:17, 25. Mär. 2013 (CET)
thread_title:  Komplettüberarbeitung 

message: Eine IP hat in dem Kapitel das, was ich geschrieben habe, offensichtlich nicht verstanden und zu dem nun da stehenden Unsinn "verbessert":
::Da jeder Aufruf eines externen Programmes den aufwendigen Systemaufruf fork() erfordert, sind Shell-interne Methoden, etwa die sogenannte Variablenexpansion, selbst wenn sie deutlich länger zu schreiben sind, bei kurzen Texten dem Aufruf von externen Programmen überlegen.[6] Bei größeren zu verarbeitenden Datenmengen erweisen sich tr, sed, awk & co hingegen als sehr effizient.
Leider hat das überhaupt nichts mit der Größe der Datenmenge zu tun, sondern lediglich mit dem modus operandi: wird der Textfilter (awk, sed, ...) innerhalb einer Pipeline verwendet UND ist die Ausgabe eine Datei bzw. Stream - was implizit bedeutet, daß er nur ein einziges Mal aufgerufen wird - ist das Filterprogramm vorzuziehen. Werden Variableninhalte ausgegeben ODER der Filter innerhalb einer Schleife aufgerufen, so ist die Variablenexpansion der Shell vorzuziehen. Die folgenden beiden Beispiele erläutern das:
 <liste von Werten> | while read value ; do
      value="$(print - "$value" | <filterprogramm>)"
      do_something "$value"
      something_else "$value"
 done
In diesem Fall ist <filterprogramm> falsch und sollte durch Variablenexpansion ersetzt werden, selbst wenn das mehrere Zeilen Code erfordert - weils nämlich wesentlich schneller in der Ausführung ist. Je größer die Textmenge wird, desto deutlicher wirkt sich das übrigens aus, also das Gegenteil von dem, was jetzt im Artikel steht. Hingegen:
 <liste von Werten> | <filterprogramm> > /path/to/file
 <liste von Werten> | <filterprogramm> | ...
In dem Fall ist das Filterprogramm vorzuziehen: da fork() nur einmal gebraucht wird, fällt sein Geschwindigkeitsnachteil nicht ins Gewicht und die Effizienz der Filterprogramme wirkt sich aus - umso stärker, je größer die Datenmenge ist.
Genau das kommt übrigens auch bei der von mir angegebenen Quelle, einer Internetdiskussion über eben dieses Thema, raus.
--bakunin (Diskussion) 10:10, 14. Mai 2013 (CEST)
replies: text: Ja, die Datenmenge ist eher irrelevant.  Die Anzahl der fork()s kann zum Problem werden, wenn sie groß wird, weil z.B. in einer Schleife angestossen. Aber derartige Effizienz-Betrachtungen sind auch nicht immer relevant, manchmal ist die langsamere Variante in der Praxis gut erträglich.  Außerdem hat das nicht so viel mit "sed" zu tun, es betrifft auch alle anderen Programme, die per fork() in Szene gesetzt werden. Allerdings ist es tatsächlich eine häufige/typische Verwendung von "sed", so daß ich den Abschnitt "Praktische Grenzen" befürworte. Da wir hier eine Enzyklopädie sein wollen, und kein Tutorial für Shell-Programmierung, sollte der Abschnitt dazu aber wirklich knapp gehalten bleiben. Und die irreführende Begründung sollte natürlich korrigiert werden. --H.Marxen (Diskussion) 13:37, 15. Mai 2013 (CEST)
thread_title:  Praktische Grenzen in der Shell-Programmierung 

message: Ich habe den Artikel von Grund auf neu geschrieben, ein bißchen Feinschliff an den Formulierungen und vermutlich ein par Tippfehler werden in den nächsten Tagen noch ausgemerzt.
--bakunin (Diskussion) 04:40, 27. Mär. 2013 (CET)
replies: text: Hmm, da sollten wir uns an dem Artikel zu Unix orientieren. Es sollte so gehalten werden, wie es dort geschrieben wird, also so gelassen werden. Da steht auch was dazu: Unix#Der_Name_Unix. --ri st (Diskussion) 00:17, 30. Mär. 2013 (CET)
thread_title:  Review 18. SW 

message: Die Open Group legt großen Wert darauf, das Betriebssystem (bzw. dessen Spezifikation), an dem sie die Rechte hält, eben nicht "Unix", sondern ausschließlich "UNIX" (allenfalls in Kapitälchen) zu nennen. Alles andere betrachten deren Anwälte (und die sind nicht gerade zimperlich) als Verletzung ihrer Markenrechte. (Mitarbeitern der Austin Group wird das so lange eingehämmert, bis sie "Unix" nicht einmal mehr denken, geschweige denn schreiben können.) Es gab einige Prozesse aus genau dem Grund und ich frage mich, ob man das nicht besser vermeidet. Ist es möglich, den Titel auf "sed (UNIX)" zu ändern?
--bakunin (Diskussion) 15:38, 27. Mär. 2013 (CET)
replies: text: Hmm, da sollten wir uns an dem Artikel zu Unix orientieren. Es sollte so gehalten werden, wie es dort geschrieben wird, also so gelassen werden. Da steht auch was dazu: Unix#Der_Name_Unix. --ri st (Diskussion) 00:17, 30. Mär. 2013 (CET)
thread_title:  Offene Fragen