Diskussion:Sed (Unix)

Zu viele Beispiele?

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)

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)

OK, hab ich wieder rausgenommen. Gruß --Flo12 22:41, 4. Sep 2006 (CEST)

UTF-8 ?

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)

RegEx Syntax?

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)

Problem mit gsed407x

Nun hab ich GNU sed v4.0.7 unter XP mal probiert um Zeilenumbrüche statt Leerzeichen an nach gewissen Textbausteinen einzufügen.

Das Kommando "s/String /String\n/g" hat nicht funktioniert. Nun habe ich mir Hilfe bei Ascii Das Kommando "s/String /String\x0D/g" hat funktioniert, ersetzt die Leerzeichen aber nur mit 0D0D und nicht noch 0A0A ein (mit einem Hexeditor hab ich das Ergebnis mir angeschaut). Das Kommando "s/String /String\x0D\x0A/g" ersetzt die Leerzeichen nur mit 0A, genauso wenn ich es fordere mit "s/String /String\x0A/g".

Mit "s/String /String\x0D \x0A/g" schreibt er nach dem String ein 0D, dann ein 20, gefolgt von einem 0A, was aber auch nicht das ist, was ich möchte.

Nun habe ich gesehen, dass es auch noch ein sed in DJGPP gibt als sed421b.zip und sed421d.zip.

Mal schauen was die macht.

--Baureihe156 (Diskussion) 09:17, 30. Jun. 2012 (CEST)

Hier handelt es sich nicht um ein Problem mit "sed". Was innerhalb der doppelten Tüddel passiert, und wie dort die Backslashes interpretiert werden, ist eine Angelegenheit der Shell. Wenn man möchte, dass "sed" ein echtes Newline-Zeichen hantiert, dann muß man das tatsächlich literal an den "sed" übergeben, denn er hat keine eigene Notation dafür.

Bleibt die Frage, wie die Shell ein Newline in einen String bekommt. Die einfachste Antwort für den klassischen SH ist: einen Zeilenumbruch mit einfügen:

NL="
"
sed "s/String /String$NL/g"

--H.Marxen (Diskussion) 15:42, 30. Dez. 2012 (CET)

Was H.Marxen gesagt hat, stimmt schon, es gibt aber noch einen weiteren Aspekt zu beachten: historisch codiert XP (wie auch MS-DOS, von dem es in vielerlei Hinsicht abstammt) den Zeilenumbruch mit 2 Zeichen, "x0Dx0A". Der Grund ist, daß MS-DOS sich dadurch eigene Druckerfilter für ASCII Text sparen konnte, weil diese beiden Zeichen - Wagenrücklauf und Zeilenvorschub - nur nativ an den Drucker gesendet zu werden brauchten. UNIX hingegen codiert den Zeilenvorschub durch ein Newline, weshalb auch sed mit nur einem Zeichen rechnet. Was H.Marxen macht, das ist, die beiden Zeichen (oder womit auch immer das Zeilenende codiert ist) in eine Shell-Variable zu packen und die dann durch die Shell expandieren zu lassen.

--bakunin (Diskussion) 15:02, 1. Mär. 2013 (CET)

Sachliche Fehler im Artikel

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: [1]. 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)

Komplettüberarbeitung

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)

Praktische Grenzen in der Shell-Programmierung

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)

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)

Review 18. SW

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)

Offene Fragen

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)

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)