[cr] entfernen nach suchmuster

[mclien]

Ich habe hier eine Text Datei (ist aus pdf konvertiert), die leider nach JEDER Zeile ein [cr] hat.

Nun will ich das ungern von Hand editieren (4 Dateien je 300 Seiten). Aber mit der Entfernung aller [cr], die nicht direkt auf einen Punkt folgen wäre mir schon geholfen, denke ich. Sich geht das auch mit sed vermute ich mal, bloß wie?
wie identifiziert man z.B. ein Zeilenumbruch?

[Meillo]

Meinst du CR (= '\r', dez:13) oder LF (= '\n', dez:10)? Erstere kommen in Unix nämlich üblicherweise nicht vor, und wenn man will man sie normalerweise nur entfernen. (Dies lässt sich mit

Code: Alles auswählen

tr -d '\r'

bewerkstelligen.)

Sich geht das auch mit sed vermute ich mal, bloß wie?
wie identifiziert man z.B. ein Zeilenumbruch?

Eigentlich kann sed keine Zeilenumbrüche (also LF, '\n', dez:10) adressieren. Mit gsed ist das trotzdem möglich, aber meist ein Gewurstel.

Wenn's doch um CR ('\r') geht, dann sollte

Code: Alles auswählen

sed 's/\.\r/./g'

weiterhelfen.

[mclien]

es geht um den Zeilenumbruch, also aus:

an jeder dem Zeilenende
auch mitten im Satz, bricht
der Text um.
Und bei den Absätzen so wie
so was etwas nervt, wenn man
für Handhelds konvertiert.

will ich quasi das machen:

an jeder dem Zeilenende auch mitten im Satz, bricht der Text um.

Und bei den Absätzen so wie so was etwas nervt, wenn man für Handhelds konvertiert.

Die bedingung wäre also:
entferne jeden Umbruch, AUSSER er steht direkt hinter einem Punkt

Das hier habe ich wo anders geklaut:

sed ':a;N;$!ba;s/\n/ /g' text.txt

Das entfernt aber ALLE Umbrüche...

[Meillo]

es geht um den Zeilenumbruch

Also geht's um LF (= '\n')

Die bedingung wäre also:
entferne jeden Umbruch, AUSSER er steht direkt hinter einem Punkt

Das hier habe ich wo anders geklaut:

sed ':a;N;$!ba;s/\n/ /g' text.txt

Das entfernt aber ALLE Umbrüche...

Das lässt sich leicht ändern; du musst nur die RegExp anpassen.

Code: Alles auswählen

sed ':a;N;$!ba;s/\([^\.]\)\n/\1 /g' text.txt

Das sollte zumindest mal gehen.

... mal sehen ob ich noch 'ne schönere Lösung finde.

[Meillo]

... mal sehen ob ich noch 'ne schönere Lösung finde.

Ja.

Code: Alles auswählen

awk '{ printf("%s%s", $0, /\.$/ ? "\n" : " ") }'

[mclien]

Supi, bloß versteh ich von awk noch weniger als von sed (und das ist schon wenig)

Zudem ist mir noch aufgefallen, daß ich doch noch mehr Absätze habe die erhalten werden müssen:
Alles was auf ' " ' und ' ? ' endet beispielsweise. ich habe das mal auf meinem niedrigen Niveau so gelöst:

Code: Alles auswählen

### alle Zeilenumbrüche durch '@' ersetzen
sed ':a;N;$!ba;s/\n/@/g' text.txt > text_mit@.txt

### alle '.@' durch '.\n' ersetzen
sed 's/\.@/.\n/g' text_mit@.txt > text_richtige_absaetze.txt

### alle verbleibenden '@' durch ' ' ersetzen
sed 's/@/ /g' text_richtige_absaetze.txt > text_fertig.txt

in der mitte kann ich dann noch die erwähnten andern kombinationen einfügen: \"@ \?@

aber awk kann das wahrscheinlich in einem Zug nehme ich an...
(ich muss meinen Chef mal überreden mir sed und awk Kurse zu finanzierren )

[Meillo]

Zudem ist mir noch aufgefallen, daß ich doch noch mehr Absätze habe die erhalten werden müssen:
Alles was auf ' " ' und ' ? ' endet beispielsweise. ich habe das mal auf meinem niedrigen Niveau so gelöst:

Einfacher geht's wenn du eine Zeichenklasse einführst:

Code: Alles auswählen

awk '{ printf("%s%s", $0, /[\.\?"]$/ ? "\n" : " ") }'

aber awk kann das wahrscheinlich in einem Zug nehme ich an...

So ist es, aber das ginge bei sed auch -- sind halt RegExps. Ich sag nur: http://xkcd.com/208/

(ich muss meinen Chef mal überreden mir sed und awk Kurse zu finanzierren )

Das ist einfach: Er muss dir nur zwei Tage deiner Arbeitszeit dafür bereitstellen (wenn überhaupt).

In einem Tag lernst du sed (quasi aus der Manpage). Eigentlich brauchst du dazu kaum einen halben Tag, dann kannst du alle seine Funktionen.

Wenn du sed und C kannst, dann kannst du fast schon awk. Somit bist du nach einem Tag mit awk fit damit. Auch hier brauchst du kaum mehr als die Manpage.

Die Kunst ist sowieso nur die Möglichkeiten der Sprachen auszuschöpfen, denn die Sprachen selbst sind recht einfach zu lernen. (Das schwierigste ist fast schon das Zeilenbearbeitungskonzept.)

Zuerst aber solltest du Reguläre Ausdrücke lernen. Die liegen beiden Sprachen zu Grunde. Dafür geht dann der Rest der zwei Tage drauf. Wenn du RegExps wirklich lernen willst, dann kommst du nicht um den ``Friedl'' rum. Sein Buch ``Regular Expressions'' (O'Reilly) ist das beste Buch zum Thema und eines der besten Computerbücher die ich gelesen habe.

[mclien]

Wenn du sed und C kannst, ...

OK C fehlte noch auf meiner Liste
Das Problem ist, denke ich das ich die Dinge nur immer alle paar Monate brauche... (eben nur zuhause) und nicht permanent bei der Arbeit in Übunge bleibe.
Aber danke für die Tipps.

[chrisbra]

[

Code: Alles auswählen

sed ':a;N;$!ba;s/\([^\.]\)\n/\1 /g' text.txt

Das sollte zumindest mal gehen.

... mal sehen ob ich noch 'ne schönere Lösung finde.

Was gefällt Dir denn nicht an der sed Lösung? Mal abgesehen davon, dass man sowas natürlich auch mit Perl, awk oder $Scriptsprache machen kann.

Grüße,
Christian

[Meillo]

... mal sehen ob ich noch 'ne schönere Lösung finde.

Was gefällt Dir denn nicht an der sed Lösung?

Sie ist mir zu kompliziert.

Was ist einfacher zu verstehen:

Code: Alles auswählen

sed ':a;N;$!ba;s/\([^\.?"]\)\n/\1 /g' text.txt

oder

Code: Alles auswählen

awk '{ printf("%s%s", $0, /[\.\?"]$/ ? "\n" : " ") }'

?

Für mich ist die Antwort klar: Die AWK-Zeile -- deren Funktion ist nämlich offensichtlich.


Wenn bei sed Sprünge gebraucht werden ist das ein Zeichen dafür, dass man nach einer Alternative suchen sollte. Nicht zwangsläufig, aber oft.

Zudem ist das sed-Script nicht portabel, da Labels bis zum Zeilenende gehen. Man müsste es also in mehreren Zeilen schreiben.

[chrisbra]

Sie ist mir zu kompliziert.

Eigentlich nicht. Einfach die komplette Datei einlesen und dann halt ersetzen. Gut die Syntax von sed ist nicht sonderlich einprägsam, aber man gewöhnt sich dran.

Was ist einfacher zu verstehen:

Code: Alles auswählen

sed ':a;N;$!ba;s/\([^\.?"]\)\n/\1 /g' text.txt

oder

Code: Alles auswählen

awk '{ printf("%s%s", $0, /[\.\?"]$/ ? "\n" : " ") }'

?
Für mich ist die Antwort klar: Die AWK-Zeile -- deren Funktion ist nämlich offensichtlich.

Liegt im Auge des Betrachters
Ich versteht die sed-Lösung beim lesen, awk muß ich erst drüber nachdenken, was es macht. Aber ich benutze auch kaum awk. Wenn es komplizierter wird, nehme ich gleich Perl.

Wenn bei sed Sprünge gebraucht werden ist das ein Zeichen dafür, dass man nach einer Alternative suchen sollte. Nicht zwangsläufig, aber oft.

Richtig. Wenn man Variablen braucht oder ein komplizierte mehrzeilige Regex benötigt, ist sed eigentlich nicht mehr das richtige Tool. Es geht zwar, aber schön ist es nicht gerade. Mich interessierte halt nur deine Meinung.

Zudem ist das sed-Script nicht portabel, da Labels bis zum Zeilenende gehen. Man müsste es also in mehreren Zeilen schreiben.

Müssen Sie? Ist mir neu. Aber man kann das Label natürlich trotzdem auf eine eigene Zeile setzen. Ich habe leider nur ein normales Gnu-System zum ausprobieren und kann nicht mit exotischeren sed-System testen, was manchmal praktisch ist.

[Meillo]

Was ist einfacher zu verstehen:

Code: Alles auswählen

sed ':a;N;$!ba;s/\([^\.?"]\)\n/\1 /g' text.txt

oder

Code: Alles auswählen

awk '{ printf("%s%s", $0, /[\.\?"]$/ ? "\n" : " ") }'

?
Für mich ist die Antwort klar: Die AWK-Zeile -- deren Funktion ist nämlich offensichtlich.

Liegt im Auge des Betrachters
Ich versteht die sed-Lösung beim lesen, awk muß ich erst drüber nachdenken, was es macht. Aber ich benutze auch kaum awk.

Natürlich liegt es im Auge des Betrachters. Und wenn man `:a;N;$!ba' als bekanntes Pattern annehmen kann (IMO nicht), dann gebe ich dir recht.

Wenn bei sed Sprünge gebraucht werden ist das ein Zeichen dafür, dass man nach einer Alternative suchen sollte. Nicht zwangsläufig, aber oft.

Richtig. Wenn man Variablen braucht oder ein komplizierte mehrzeilige Regex benötigt, ist sed eigentlich nicht mehr das richtige Tool. Es geht zwar, aber schön ist es nicht gerade. Mich interessierte halt nur deine Meinung.

Wie gesagt, wenn die Sprünge als bekanntes Pattern auftreten würden (also, dass man das Konstrukt erkennt ohne es genau lesen zu müssen), dann wäre es nicht komplizierter als ein einfacher Befehl.

Sonst muss man bei Sprüngen aber den Programm-Flow nachvollziehen und das ist meist die eigentliche Schwierigkeit beim Lesen von Code.

Zudem ist das sed-Script nicht portabel, da Labels bis zum Zeilenende gehen. Man müsste es also in mehreren Zeilen schreiben.

Müssen Sie? Ist mir neu.

Ich habe jetzt nochmal in der SUSv3 nachgelesen und dort nichts darüber gefunden. Auf meinem NetBSD bekam ich es aber anders nicht zum Laufen. Aber zugegeben, diese Behauptung war nicht fundiert.


Vielleicht noch ein Wort zum Thema Performance (im weitesten Sinne). Das sed-Script muss die komplette Datei einlesen (und damit im RAM halten) bevor darauf gearbeitet werden kann. Wenn die Datei 20MB groß ist wird auch soviel RAM verbraucht.

Jetzt nehmen wir noch eine alternative sed-Implementierung an, die begrenzte Zeilenlängen hat, dann wird's ziemlich schnell eng.

Das awk-Script arbeitet (wie es sed und awk tun sollen) zeilenweise und verhält sich gleich, egal wie groß die Eingangsdaten sind.

[Meillo]

Zudem ist das sed-Script nicht portabel, da Labels bis zum Zeilenende gehen. Man müsste es also in mehreren Zeilen schreiben.

Müssen Sie? Ist mir neu.

Ich habe jetzt nochmal in der SUSv3 nachgelesen und dort nichts darüber gefunden. Auf meinem NetBSD bekam ich es aber anders nicht zum Laufen. Aber zugegeben, diese Behauptung war nicht fundiert.

Jetzt wird's aber fundiert.

Mit Heirloom sed konnte ich das Verhalten reproduzieren. Nachdem ich im Code (des Heirloom sed) geeignete printf()s eingebaut hatte, *sah* ich auch was als Label hergenommen wird: Alles nach beginnendem Doppelpunkt (und eventuellen Whitespaces) bis zum Zeilenende.

Bei unserem Script heißt das Label also ``a;N;$!ba;s/\([^\.?"]\)\n/\1 /g''. Damit besteht das Script *nur noch* aus einem Label.

Whitespaces am Ende des Labels gehören bei Heirloom sed zum Label. Laut SUSv3 ist das undefiniert.

[chrisbra]

[…]Labels gehen bis zum Zeilenende[…]
Ich habe jetzt nochmal in der SUSv3 nachgelesen und dort nichts darüber gefunden. Auf meinem NetBSD bekam ich es aber anders nicht zum Laufen. Aber zugegeben, diese Behauptung war nicht fundiert.

Jetzt wird's aber fundiert.

Mit Heirloom sed konnte ich das Verhalten reproduzieren. Nachdem ich im Code (des Heirloom sed) geeignete printf()s eingebaut hatte, *sah* ich auch was als Label hergenommen wird: Alles nach beginnendem Doppelpunkt (und eventuellen Whitespaces) bis zum Zeilenende.

Bei unserem Script heißt das Label also ``a;N;$!ba;s/\([^\.?"]\)\n/\1 /g''. Damit besteht das Script *nur noch* aus einem Label.

Whitespaces am Ende des Labels gehören bei Heirloom sed zum Label. Laut SUSv3 ist das undefiniert.

Ich hab auch noch mal in SuSv3 nachgelesen und folgendes gefunden:

Command verbs other than {, a, b, c, i, r, t, w, :, and # can be followed by a semicolon, optional <blank>s, and another command verb. However, when the s command verb is used with the w flag, following it with another command in this manner produces undefined results.

Also ist laut SuSv3 der Einzeiler falsch. Stört aber Gnu Sed nicht. (Sollte man mal als Whishlist Bug reporten

[chrisbra]

Vielleicht noch ein Wort zum Thema Performance (im weitesten Sinne). Das sed-Script muss die komplette Datei einlesen (und damit im RAM halten) bevor darauf gearbeitet werden kann. Wenn die Datei 20MB groß ist wird auch soviel RAM verbraucht.

Klar. Mann kann aber ein Sed-Skript auch so schreiben, dass maximal ein Satz (was auch immer das ist) eingelesen wird. Das hier müßte funktionieren:

Code: Alles auswählen

$ cat foobar.sed
/[.?!]$/{
H
g
s/\n/ /g
p
x
s/.*//
x
}
/[.?!]$/!{
H
}

und dann halt sed -n -f foobar.sed <Datei>

(und ab hier finde ich es dann auch nicht mehr lesbar )

Wie gesagt, wenn es Batch Processing sein muß, dann würde ich zu Perl greifen, oder zur Not mit Vim scripten:
vim -u NONE -N -c ':%s/[^.!?]\zs\n\ze/ /g|:wq %' <datei>
oder viele Dateien:
vim -u NONE -N -c ':argdo :%s/[^.!?]\zs\n\ze/ /g|:wq %' <datei1> <datei2> <datei3> ....

Jetzt nehmen wir noch eine alternative sed-Implementierung an, die begrenzte Zeilenlängen hat, dann wird's ziemlich schnell eng.

Das awk-Script arbeitet (wie es sed und awk tun sollen) zeilenweise und verhält sich gleich, egal wie groß die Eingangsdaten sind.

ACK, aber man kann daran arbeiten, indem man nicht die Datei komplett einliest, siehe oben.

[Meillo]

Ich hab auch noch mal in SuSv3 nachgelesen und folgendes gefunden:

Command verbs other than {, a, b, c, i, r, t, w, :, and # can be followed by a semicolon, optional <blank>s, and another command verb. However, when the s command verb is used with the w flag, following it with another command in this manner produces undefined results.

Danke. Die Stelle habe ich nicht gefunden. (Hatte auch nach anderen Stichworten gesucht.)

Also ist laut SuSv3 der Einzeiler falsch. Stört aber Gnu Sed nicht. (Sollte man mal als Whishlist Bug reporten

Zumindest mit der Option --posix (= ``disable all GNU extensions'') sollte sich gsed standardkonform verhalten. Das wäre eigentlich schon eine Bug wert.

Ich weiß nur nicht ob sich da was ändern wird, denn bei GNU ist es meiner Erfahrung nach wichtiger, dass es funktioniert als dass Standards eingehalten werden. Nach dem Motto: Wir implementieren doch keine Unzulänglichkeiten des Standards wenn wir es auch ohne ``Fehler'' implementieren können.

[Meillo]

Wie gesagt, wenn es Batch Processing sein muß, dann würde ich zu Perl greifen, oder zur Not mit Vim scripten:

Und wieso nicht einfach awk verwenden, das auf jedem Unix zu finden ist (trifft weder auf Perl noch auf den Vim zu) und zudem eine so simple Lösung (wie oben zu sehen) ermöglicht?

[chrisbra]

Wie gesagt, wenn es Batch Processing sein muß, dann würde ich zu Perl greifen, oder zur Not mit Vim scripten:

Und wieso nicht einfach awk verwenden, das auf jedem Unix zu finden ist (trifft weder auf Perl noch auf den Vim zu) und zudem eine so simple Lösung (wie oben zu sehen) ermöglicht?

Ganz einfach: Kann ich nicht. Also zum Scripten reicht es wahrscheinlich, aber bis ich da eine Lösung habe, bin ich so schneller
Aber ich mach sowas auch nur privat und da hab ich noch kein System gesehen, wo weder Perl noch vim verfügbar waren.

[Meillo]

Wie gesagt, wenn es Batch Processing sein muß, dann würde ich zu Perl greifen, oder zur Not mit Vim scripten:

Und wieso nicht einfach awk verwenden, das auf jedem Unix zu finden ist (trifft weder auf Perl noch auf den Vim zu) und zudem eine so simple Lösung (wie oben zu sehen) ermöglicht?

Ganz einfach: Kann ich nicht. Also zum Scripten reicht es wahrscheinlich, aber bis ich da eine Lösung habe, bin ich so schneller
Aber ich mach sowas auch nur privat und da hab ich noch kein System gesehen, wo weder Perl noch vim verfügbar waren.

Klar. Ich wollte dich da nicht bedrängen. Ich weiß auch, dass nur wenige mehr awk können als '{ print $1 }' und dass es dann natürlich mit anderen Werkzeugen schneller geht.

Aber lern doch awk! So fit wie du in sed bist, brauchst du dafür keinen Tag.

[chrisbra]

Aber lern doch awk! So fit wie du in sed bist, brauchst du dafür keinen Tag.

Danke

Wenn ich mal wieder ein Problem zu lösen habe, nehm ich mir mal awk vor.

[ThorstenS]

Aber lern doch awk!

Ich nutze awk seit geraumer Zeit und mit wachsender Begeisterung. Aber deinen 'einfachen' awk-Einzeiler habe ich auch nicht auf Anhieb verstanden.
manpages lesen und verstehen sind zweierlei Dinge. Ich habe mich jahrelang sehr schwer damit getan.

Wie wäre es denn, wenn wir hier im wiki einige awk-Einzeiler posten - sozusagen als kleine Förderung des Bekanntheisgrades.

Sowas hier habe ich z.B. in meinem 'consolen-wiki' (Ordnerstruktur mit Textdateien auf der console mit glimpse-Volltextindexsuche):

Code: Alles auswählen

# Zeig mir alle Homeverzeichnisse, die nicht dem User selbst gehören
ls -l -I lost+found  /home  | awk '$3 != $8 {print $0}'

# ist ein 3Ware controller (13c1) im Server?
lspci -n | awk -F ':' '/13c1/ {gsub(/ /,""g);print $3}'

# Zeig mir alle optischen Laufwerke im System
hwinfo --cdrom | awk -F':' '/Model:/{m=$2} /Device File:/{ print $2 " " m } '
 /dev/hdb  "TSSTcorpCD/DVDW SH-S182D"

# Eine Textdatei hat verkehrte Zeilenumbrüche, sortiere sie, sodass jede Zeile mit select beginnt:
# ( ORS= Zeilentrenner, NR ist die Zeilennummer)
awk '{if($1 ~/^select/ && NR > 1){$0= "\n"$0};ORS="";print $0}'

# Bei der Migration der User von einem System auf ein anderes musste ich die UID jeweils um 1000 erhöhen:
awk -F ':' ' { print $1 ":" $2 ":" $3+1000 ":" $4 ":" $5 ":" $6 ":" $7 }' passwd.anlegen

# Anzeigen wie gross die Ordner sind:
du -sk * | sort -n | awk '{$1=$1/1024; printf("%d MB %s \n",$1,$2)}'

# nicht eingebundene extX Partitionen in Grösse und freiem Speicherplatz anzeigen:_
tune2fs -l /dev/sda5 | awk '/Block count:/{COUNT=$3} /Free blocks:/{FREE=$3} /Block size:/{SIZE=$3} END{ printf "size: %dMB\nfree: %dMB\n",COUNT*SIZE/1024/1024,FREE*SIZE/1024/1024 }'

# Festplatten inkl Seriennummer auflisten
hwinfo --disk |  awk -F':' 'BEGIN{ print "Device\t\t\Name\t\t\tSeriennummer"} /Model:/{M=$2} /Serial ID:/{S=$2} /Device File:/{ print $2 "\t" M "\t" S } '
Device          Name                    Seriennummer
 /dev/sda        "Maxtor 6Y160M0"        "Y46YBLVE"
 /dev/hda        "SAMSUNG SP0802N"       "0647J3FW542668"
 /dev/sdb        "ST3160811AS"           "6PT099WT"

# Listet USB Laufwerke auf:
# hwinfo --usb| awk -F':' '/Model:/{m=$2} /Device File:/{ print $2 " " m } '
/dev/sdc (/dev/sg2)  "Corsair VoyagerGT"

# Alle Laufwerke auflisten - nur mit awk
awk '/hd.?$|sd.?$/  {print $4}' /proc/partitions

# IP-Adresse von eth0 ausgeben:
LANG=C ifconfig | awk '/eth0/ { getline; print substr($2,index($2,":")+1)}'

# Get a list of ips with the most tracked connections:
< /proc/net/ip_conntrack awk '$4 ~/=/ { print substr($4,index($4,"=")+1)}' | sort |  uniq -c -d | sort -n

awk Ersatz für ini-Auslesen:
cat Server.ini
Logpath=/var/log/daemon.log

Um nun an den Pfad zu gelangen:
PFAD=$(awk -F= '/LogPath/{print $2}' /etc/Server.ini)
PFAD=$(sed -n '/LogPath/{s#LogPath=##;p}' /etc/Server.ini)

Wie wärs?

[Meillo]

Wie wäre es denn, wenn wir hier im wiki einige awk-Einzeiler posten - sozusagen als kleine Förderung des Bekanntheisgrades.

Nichts dagegen. Und da das Wiki ja von jedem bearbeitet werden kann (nachdem man sich einen Account angelegt hat), kannst du das ja mal reinstellen. Ich glaube Mr_Snede ist der der das Wiki so ein bisschen unter sich hat, also wäre es gut ihm kurz Bescheid zu sagen.

Ich bin nicht unbedingt der der diese Wikiseite aufbauen will, aber wenn du was hinstellst, dann ergänze ich gerne.

[ThorstenS]

ok, ich schreibe demnächst mal eine Seite im Wiki.
In der Übersichtsseite hier http://debianforum.de/forum/viewforum.php?f=36 weise ich dann auf sie hin. Das ist der übliche Weg, den ich für andere Seiten auch schon eingeschlagen habe.

[mclien]

manpages lesen und verstehen sind zweierlei Dinge. Ich habe mich jahrelang sehr schwer damit getan.

Wie wäre es denn, wenn wir hier im wiki einige awk-Einzeiler posten - sozusagen als kleine Förderung des Bekanntheisgrades.

Zustimmung zu beidem. Da ich (noch) kein awk kann hier mein Vorschlag zum einfacheren Verständnis

Beispiel:

grep -B1 linux datei.txt:

grep: get regular expression
-B1: die Gesuchte Zeile und, die davor
linux: Ausdruck/ Zeichenfolge , die in der Datei gesucht wird
datei: Datei in der gesucht wird

(geht sicher auch mit ascii art direkt darunter, aber das Forum schluckt leerzeichen)

[Meillo]

manpages lesen und verstehen sind zweierlei Dinge. Ich habe mich jahrelang sehr schwer damit getan.

Zustimmung [...] hier mein Vorschlag zum einfacheren Verständnis

Beispiel:

grep -B1 linux datei.txt:

grep: get regular expression
-B1: die Gesuchte Zeile und, die davor
linux: Ausdruck/ Zeichenfolge , die in der Datei gesucht wird
datei: Datei in der gesucht wird

Wenn ich das so lese, dann wird's mir ein bisschen unwohl.

Ich unterstütze eine Wikipage in der Beispiele zu finden sind.

Ich bin aber gegen Dokumentation die nur die Informationen der Manpages enthält. Manpages sind *die* Anlaufstelle für Informationen zur Funktion von Programmen; wenn man eben solche Informationen sucht, dann sollte man sie auch dort suchen.

Wer sich mit Manpages schwer tut, der sollte lernen damit umzugehen, alles andere sind nur Krücken auf die man meint angewiesen zu sein.

Obiges Beispiel steht genau so, aber exakter in der Manpage, deshalb sollte es hier nicht nochmal stehen. Was dagegen hier stehen sollte ist, wie man bestimmte Probleme anpacken kann und wie man bestimmte Probleme mit verschiedenen Tools lösen kann. Damit kann man Wissen über ein Tool auf ein anderes transferieren -- darum geht es.